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Preface 


Structured Systems Analysis and Design 


| Computer information systems are the heart of daily activities and a major 
| consideration in corporate decision making. Just as knowledge of computers and 


oa? 


=e 


| computer programming has become a basic skill needed to survive in today’s 


information-based society, so has the design of business systems. The development of 
information systems involves both systems analysts and those who will use the 
applications that emerge i.e. end-users. The analysis and design of computer systems 
involve many parts of the organisation and are not limited to the domain of computer 
specialists. 


The objective of this book is to involve students in the systems thinking activity that 
is essential for the design and development of business systems. The chapters in the 
book guide you through the systems development life cycle and explain the techniques 
used in each phase. After a brief introduction to structured analysis and design 
techniques in the first chapter, the rest of the chapters explain how to use each of 
these structured techniques. Although various methodologies are available for analysis 
and design, this book focuses on structured techniques which is one of the widely 
used methodologies. 


It is our continuos endeavour to bring to you the latest, the best and the most relevant 
matter related to computers. 


The material in this book is brought to you by the Design team. The process of design 
has been part of the ISO 9001 certification for Aptech - IT division. Education Support 
Services. As part of Aptech’s quality drive, this team is continuously researching and 
improving upon the curriculum to keep it in line with the industry trends. 


This research and development team will be glad to receive any suggestions. The 
students must feel free to send feedback to the Design Head at Aptech’s Head Office, 
Bombay. 


Design Team 
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Chapter 1 


System Concepts 


At the end of this session, you will be able to: 

> ‘Understand what a system is 

> Define categories of information systems 

> Identify the various phases of the systems development life cycle 
> Write a feasibility report for a system 

=> Know the various fact finding techniques 


=> Know the job of a systems analyst and the qualities of an analyst 


1.0 Introduction 


We use the computer technology in many ways, from visible to invisible, 
spectacular to routine, video games and special effects for films and 
television to microwave ovens, electronic cameras, and automobile 
ignition systems. In business too, computers and information systems 
occupy a special place: Computers make possible the smooth and 
efficient operation of airline reservations, hospital record departments, 
accounting and payroll functions, electronic banking, telephone 
switching systems and countless other operations both large i and. small. 


How do such complex information systems “come into existence? 
Obviously through people. Technology has developed ata very fast rate, 
but the most important aspect of any system is the human know-how 
and the use of ideas to gear the computer so that it performs the 


required task. This process is essentially what systems development is 
all about.’ ue í 


To be of any use, a apate weak information _system must function 
properly, be easy to use, and suit the organisation for which it has been 
designed. If it helps people do their jobs better and more efficiently, they 
will use it. If it is not helpful, they will surely avoid it. 
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1.1 What is a system 


Systems are, in fact, all around us. For example you experience 

physical sensations by means of a complex nervous system which 

consists of parts, including the brain, spinal cord, nerves, and special 
sensitive cells that work together to make a person feel hot, cold etc. 


A person communicates by means of a language, a highly developed 
system of words and symbols that convey meaning to each other . We all 
live according to an economic system in which goods and services are 
exchanged for other goods and services of comparable value and by 
which the participants to the exchange are benefited. 


A system is simply a set of components that interact to accomplish some 


purpose. 
Or 


A system is an orderly grouping of interdependent components linked 
together according to a plan to achieve a specific objective. 


The components that make up systems may actually be other smaller 
systems; that is, systems may be made up of levels of systems, or 


subsystems. 


Organisations consist of many business systems, each having the 
features of the general system. 


The purposes of information systems are to process input, maintain files 
of data about the organisation, and produce information, reports, and 
other output. 


An Information System can be defined as a subsystem of the business. 
Specifically, it is an arrangement of interdependent human and machine 
components that interact to support the operational, managerial, and 
decision-making information needs of an organisation. 


Information systems consist of subsystems, including hardware, 
software, and data storage for files and databases. The set of 
subsystems that uses - the specific equipment, programs, files, and 
procedures - constitutes information systems application. Thus, 
information systems can be purchasing, accounting, payroll or sales 
applications. 
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1.2 Categories of Information Systems 


Systems analysts develop different types of information systems to meet 
a variety of business .needs. The types of Information systems and a 
brief description of each are listed below :- 


1. 


Data Processing Systems 


Processes large amountiof data for routine business transactions, 
these systems run a series of programs on an automatic basis at 
regular intervals. 

e.g. Payroll, inventory, financial accounting etc. 


Management Information Systems [MIS] ; ni 


Provides periodic reports for planning, control and decision making. 
Users of MIS use a shared database. MIS generates information that 
is used in decision making. 


Decision Support Systems [DSS] 


DSS supports decision makers by providing information on 
demand . DSS is similar to MIS, in that, they both depend on a 
database as a source of data. DSS differs from MIS in that it 
emphasises the support- of decision making in all of its phases. 
Though, the actual decision is still in the hands of the decision 
maker. 


Expert Systems 


Expert systems capture expertise of decision makers in solving 
problems. They are a very special class of information systems 
made available for business, with the recent and widespread 
availability of hardware and software, such as, microcomputers and 
expert systems shells. An expert systems (also called knowledge 
based system) effectively captures and uses the knowledge of an 
expert for solving a particular problem experienced in an 
organisation. E.g. medical system, judicial system. 


Unlike DSS which leaves the final judgement to the decision 
maker, an expert system selects the best solution available to a 
problem or a specific class of problems . 
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Data being processed in each of these systems may be done using any 
of the following modes: 


+- On-line processing 
æ Batch processing 


# Transaction processing. 
1.3 What is Systems Analysis and Design 


Systems development has two major components, Systems Analysis 
and Systems Design. Systems analysis and design refers to the process 
of examining a business situation with the intent of improving it 
through better methods and procedures. Systems design is the process 
of planning a new business system to replace the old. But before this 
planning can be done, we must thoroughly understand the old system 
and determine how the computer can be best used to. make its 
operation more effective. 


Systems analysis then, is the process of totally understanding the 
current system by gathering and interpreting facts, diagnosing 
problems, and using the facts to improve the current system. This 
is the job of the Systems Analyst. 


Having determined the requirements and ‘what’ the system is intended 
to do, the systems designer designs the new system keeping in mind the 
objectives set during the systems analysis. This job is either done by the 
systems analyst himself or by another person called systems designer. 


Thus, Analysis specifies ‘what’ the system should do, that is it sets the 
objective and Design states ‘how’ to accomplish this objective. 
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1.4 Systems Development Life Cycle (SDLC) 


As already mentioned Systems development is a process consisting of 
the two major steps of Systems Analysis and Design. It starts when 
management or the systems development personnel realise that a 
particular business system needs improvement. 


The Systems development life cycle is a sequence of events carried out by 
analysts, designers and users to develop and implement an information 
system. These activities are carried out in different stages. 


Generally speaking, the phases of a project should be completed in 
sequence. Unfortunately most life cycles leave you with the impression 
that you must finish one phase or task before starting the next. In 
reality phases of systems development life cycle canoverlap. Each phase 
is subject to change, based on the outcome of reviews held at the end of 
each phase. 


This section examines each of the seven events that make up the 
systems development life cycle. We will follow the’ waterfall life cycle 
approach. Most systems activities are.all closely related and are usually 
inseparable. Even the order: of the steps in ‘these activities maybe 
difficult to determine. Different partsof the project can be in various 
phases at the same time. Some components maybe undergoing analysis 
while others are at advanced design stages. 


Ans: 1) A system is an orderly grouping of þrtardepgadeni components linked together according to a plan to 
achieve a specific objective. 
2) What, how abn es 
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Determination Of § 
Systems 
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Figure 1.1 Phases Of Systems Development Life Cycle 
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The Phases are as follows :- _ 


rrol 


1. Preliminary investigation (feasibility study) 
2... Determination of Systems requirements 

3. Design of the system 

4. Development of software 

5. _ Systems testing 

6. Systems implementation 

7. Systems Maintenance 


Here is an overview of each of these activities. = 


1.4.1 ;. Preliminary Investigation (Feasibility Study) 


One must know what the problem is before it can be solved. This phase 
starts as soon as someone, either a user or a member of a particular 
department recognises a problem or initiates a request, to modify the 
current computerised system, or to computerise the current manual 
system. When the request is made, the first systems activity, which is 
the. preliminary investigation begins. An important outcome of .the 
preliminary investigation is determining whether the system 
requested is feasible or not. 


The study is carried out by a small group of people who are familiar with 
information systems techniques, understand the part of the business or 
organisation that will be involved or affected by the project,. and are 
skilled in systems analysis and design process. Fact-Finding techniques 
are made use of to gather the required information. These are discussed 
latter in this session. 


The major purposes of this study are listed below: 


> Identify the responsible users and develop an initial “scope” of 
the system. This may involve conducting a series of interviews. to 
see which user(s) are involved in (or affected by) the proposed 
project and which are not. The scope of the system is determined 


a E a 
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based on the information collected from the users. The scope 
determines the functionality of a system. 


> Identify current deficiencies in the user’s environment. This will 
usually consist of a simple narrative list of functions that are 
missing or operating unacceptably in the current system. The 
process of identifying deficiencies may also throw up the need for 
modifications/ enhancements to the existing system. 


> Determine objectives for the new system. This may also be a 
narrative list consisting of existing functions that need to be re- 
implemented, new functions that need to be added, and 
performance criteria for the new system. 


> Determine whether it is feasible to automate the system and, if 
so, suggest some acceptable options. This will involve some very 
crude and approximate estimates of the schedule and cost to build 
a new system. 


The three major areas to consider while determining the feasibility 
of a project are: 


Technical feasibility : The analyst must find out whether current 
technical resources which are available in the organisation is 
capable of handling the user’s requirements. 3 

` If not, then the analyst with the help of vendors should confirm ' 
whether the technology is available and capable of IARI the 
user's request. 
Economic feasibility :. Economic or financial feasibility is the 
second part of resource SLL. The basic resources to 
consider are : 
¢ Management time ~ 

¢ Time spent by the systems analysis team 


_ © Cost of doing the full systems study (including time of employees 
~ you ‘will be working with) s : 


e Estimated cost of hardware 


e Estimated cost of software and I or software ER 
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The concerned business must.be able to see the value of the 
investment it is considering before committing to an entire systems 
study. If short term costs are not overshadowed by long term gains, 
or there is not an immediate reduction in operating costs, then the 
system is not economically feasible and the project . should not 
proceed any further. 


Operational feasibility : Once it is determined that the system is 
both technical and economically feasible then it has to be seen if it 
is operationally feasible: Operational feasibility is dependent upon 
determining human resources for the project. It refers to projecting 
whether the system will operate and be used once it is installed. 


If the ultimate users are virtually weded to the present system and 
they see no problem and if they are not involved in ‘requesting for a 

' new system, then resistance to its operation will be strong. Chances 
for the system ever becoming operational are low. 


Alternatively; if users themselves have expressed a need for an 


improved system, then they will put in-all‘efforts to see that it 
becomes operational, and will eventually use it. 
P) - i 2 . a? -j 


OUST AS 
` 


The document to be produced at the end of this activity is called 
“Feasibility Study Report”. ; 


Ans :“1) Data processing system, Management Information System & Decision Support System ~ ` 
2) Feasibility study, System requirement (analysis), System design, Development of software, Testing, 
Implementation, and Maintenance 


We will now present a Case Study. The guidelines for preparing a 
feasibility report for this project is presented after the case study. 
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Case Study - Payroll System 


For our case study, we have chosen the payroll system: of ABC Co. Ltd., 
which is a very familiar and simple system. Reference to this case will 


be made through out the book. 
2 Organisational Overview Of ABC Co. Ltd. 
“Payroll System” for ABC Co. Ltd. 


ABC Co. Ltd. is the only sales outlet in Bombay for certain consumer 
goods. It basically consists of three departments. 


1. Sales department: Employees of this department are involved with 
the order processing system of the company. They carry out all the 
sales activities. 


2. Accounts department : This department is involved with all the 
financial accounting aspects of the company. 


3. Administration department: The major activity of this department, 
is payroll processing of all departments, and recruitment of new 


personnel. 
One of the jobs of administration department, is to calculate the payroll 
of the entire company. This so far is being done manually. The 
administration manager finds it very time consuming and feels that this 
system should be automated. 


@ Current manual system 


At present the administration department maintains three separate 
employee registers, one for each of the three departments of the 
company. The payroll is processed separately for each of the three 


departments. 
As and when any new employee joins, the appointment form containing 


all the employees standard details are sent to the administration 
department. These details are entered in the respective department’s 


register. 


A few months ago, a particular new employee - Anil’s, details from the 
appointment form were entered by the administration clerk Joe, in the 
sales department register instead of the accounts department register. 
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This mistake was realised after the entire processing was complete. 
When the accounts department could not locate Anil’s payslip, they 
approached the administration department. Joe, who had actually 
entered the register was absent. Another clerk Kumar, denied receiving 
Anil’s appointment form. He checked the accounts department’s 
employee register and argued that if it had come then the details would 
have been written into this register. The details were finally entered in 
the accounts department employee register, and the payslip for Anil was 
prepared. 


After a week when Joe resumed duty he was informed by Kumar as to 
how he had to oblige the accounts department by preparing Anil’s 
payslip after all the work was done. At that time Joe realised his 
mistake. He then had to cancel the information from the sales 
department employee register. Anil’s payslip which had actually been 
prepared and sent to the sales department was found lying on the desk 
of the sales clerk who had distributed the payslips. 


Just as the appointment form is sent to the administration any. changes 
in the employee details are also sent by the respective departments, and 


- these changes are incorporated in the respective registers, 


By the 20th. of every month, the departments send in their attendance 
registers and overtime registers. The accounts department in addition, 
sends in the advance salary voucher details of all employees. : 


employee. 

There have been many instances when these figures have been wrongly 
calculated, resulting in under or over payment. Naturally, the under 
payments have been reported while only few over paid cases have been 
reported. 

Having completed this, the payroll of each department is calculated 
separately using the employee register details, days absent details, total 
overtime hours and advance salary details, the monthly payroll 
statement for each department is prepared. This statement is used as 
basis for preparing payslips, bank statement and salary summary 
statements. 
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Again there are a number of instances when: 


1. The figures appearing in the payslips do not tally with the payroll 
statement or the bank statement. 


2. The figures appearing in the bank statement are wrong. 
3. The salary summary statement does not tally. 


All this causes a great amount of chaos and confusion every month. All 
these problems were reported to the management on various occasions. 
It was finally decided to computerise the Payroll Monitoring function of 
the company. 


‘Success Consultants’ were entrusted with the development of the entire 
Payroll system of the company. They were asked first to carry out a 
feasibility study and hand over a feasibility report to the management. 


Guidelines For Preparing A Feasibility Report For The Automation 
Of The Payroll System For ABC Co. Ltd. 


2 Identify the Responsible Users and Develop an Initial ‘Scope’ of 
the system 


The analyst must identify two specific groups of end-users: 


a. Those who use the system. In this case the officers and clerks who 
actually collect the data and calculate the payroll. 


b. Those affected by the inputs and outputs of the system in study. In 
this case the Accounts department who should receive the accounts 
statement, and all those in the administration department who are 
involved with the inputs and outputs. 


To develop the initial scope of the system you necd to get a broad idea of 
the system in study. In this case we can identify the main process as 
‘the payroll monitoring process’, which gets its inputs from the three 
departments of the company, which are the sales department, accounts 
department and the administration department. The outputs of the 
systems are sent back to the respective departments. 


Besides, we need to develop an initial context diagram -which is a 
simple data flow diagram in which the entire system is represented by a 
single process. (The context diagram is described in chapter 2). 
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a Identify current deficiencies in the user’s environment 


As the payroll processing is being done separately for each of the 
departments, there is duplication of registers, and processes. 


As there are separate registers maintained, very often the entrie& are 


entered in the wrong registers, causing duplication of work and 
confusion. 


Errors in calculation result in employees being wrongly paid, which 
need to be rectified in the following month. 


Payslips and all the required reports have to be typed out. This is not 
only very laborious and time consuming but there are a number of 
errors found. Very often the statements do not tally. 


© Determine Objectives fora new system `` 
Here we will briefly list the functions of the new system. 


> Maintenance of a employee details in a central location. 
Entry of new employee details. 
Updation of old employee details. 


> . Maintenance of a transaction details, and calculation of the days 
absent . and Total ‘overtime hours of ‘the month using the 


attendance details and daywise overtime details obtained from the 
departments. 


> Maintenance / check list printing o f current month’s transaction 
details: 


> Calculation of payroll and generation of the cartes qo 
> Generation of monthly reports : 

- Payslips 

- Cheques 

- Bank Statement (Paymiest advice) 

- Salary Summary Statement 
2 : - Accounts Statement ( for seront 

-PF Statement ` 
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Generation of Yearly Reports: 
- Consolidated salary statement 
- Bonus Statement 


y 


Adhoc reports ( as and when required) 
- List of employee of particular grades ; 5 
- List of employees whose basic salary is between the given 


p Tange. 


Y 


a Determine whether it is feasible to automate the system 


The Analyst discusses goals and objectives for the new system in a 
review with the administration manager, officers, clerks handling the 
payroll and the company manager. 


The administration manager considers the following three major areas 
to determine the feasibility of this project. 


Technical feasibility : He determines whether the current level . of 
technology can support the proposed system. ABC Co. ltd., already has 
hardware installed. This, at present is being used by the accounts 
department. They are in a position to spare one terminal to the 
administration department. The current set up is sufficient for the 
processing of the payroll once a month and even for adhoc reports as 
well as the annual reports. 


Economic feasibility: He measures the cost effectiveness of the project. 
He now need not invest in the hardware as it is already: available. He 
will still need to consider the time spent by the systems analysis’ team, 
the cost of doing a full systems study, cost of employee’s time involved 
in the study and the cost of the development of the software which has 
been entrusted to ‘Success Consultants’ . 


Operational feasibility : He considers the extent the proposed system will 
fulfil his department’s requirements:, That is whether the proposed 
system covers all aspects of the working system and whether it has 
considerable improvements. In this case the employees of the 
administration department themselves have made the: request to 
computerise the payroll system. They are very keen to see it operational. 


On having decided that they should go ahead, they request ‘Success 
Consultants’ to carry out the Analysis and Design of.the company’s 
payroll system. : 
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1.4.2. Determination of Requirements (Analysis) 


After the feasibility study is done, a formal acceptance of the proposed 
system is taken from the user. The feasibility report is then taken as the 
basis for the next activity. 


The next activity is Determination of Systems requirements, which 
involves studying the current business system in great detail, to find out 
how it works and where improvements have to be made. A requirement 
is a feature that must be included in a new systemIt may include a way 
of capturing or processing data, producing information, controlling a 
business activity, or supporting management. 


The determination of requirement thus includes studying the existing 
system and collecting data (using the fact finding techniques discussed 


in section 1.5) about it to find out what the requirements are. This 
activity maybe carried out in two phases. 


a. Detailed investigation 

The heart of systems analysis is aimed at having a detailed 
understanding of all the important facets of the project under 
consideration. Analysts working closely with employees and managers 
must be able to answer the following key questions :- 

i) What is being done by the current system? 

ii) Howitis being done ? 

ii) How frequently does it occur ? 

iv) How big is the volume of transactions or decisions ? 

v) How well is the task being performed ? — 
vi) Doesa problem exist ? 

vii) Ifa PODIE] Bards how. serious it. is D ae 


Wie Ifa a problem exists, what is the underlying cause ? 


To answer the ahave questions eters ‘analysts talk to a Roce of 
_ people to gather details about the sabe decease are used to 
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collect this information from large groups of people who cannot be 
interviewed individually. . 


Detailed investigations also require the study of manuals and reports, 
actual observation of work activities and collection of existing forms and 
documents to fully understand the project. 


As the details are gathered, the analyst studies, the requirements and 
identifies features the new system should have. The features include 
the information the system should produce and operational features 
such as processing controls, response times and input and output 
methods. 


b. Analysis or Determination of systems requirements 

After having understood the system, the next phase is to carry out a 
detailed study of the various operations performed by the system and 
their relationships within and outside the system. It is during this 


phase that the analyst and the user come to an agreement on what 
functions the proposed system has to perform. 


A detailed document has to be prepared by the Systems Analyst 
containing the following :- 

1. Inputs that must be received by the system. 

2. The outputs to be produced by the system. 

The data to be retained. 


The procedures to get the output from the given inputs. 


WO es ee 


Audit and Control requirements - This would specify the features/ 
functions/ procedures that are required for the user to monitor and 
ensure that the new system is working properly or not. 


6. System Acceptance Criteria - This would list the tests that the user 
would actually perform to check if the system is acceptable or not. - 


mp ia 2r ž ‘ 
This detailed document is called the Functional Specification or 
Proposed Procedures. ~ i 3 yp 
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At the end of this phase, the analyst should conduct a walkthrough with 
the users to review the specifications for various aspects of the analysis. 


1.4.4. Design of the System 


Once analysis is completed, the analyst has a firm Tasandi of 
what is to be done. The next step is how the problem can be solved. The 
design of a system uses the Functional Specification as basis and 
produces the details that state how a system will meet the requirements 

identified during systems analysis. The design process should take care 

of the following: pices 


e Identification of reports and outputs the: new system should 
produce. 


e  Scrutinise the data present on each report/output. 


* Sketch the form or display as expected to appear at the end of ` 
completion of the system. This maybe done on paper or on a 
computer display, using one os the alitomated system design 
tools. available. | S 


DT Descriptión of data to be Bee paiement ‘or stored. 


. Individual data items and. calculation procedures are written in 
detail. : 


« The procedures written should tell how to process the cata and 
produce the output. 


The document produced at the end of this activity is called the A 
Specification”. This document should have charts, tables and special 
symbols to portray the design. Ri 
Designing tools are used to facilitate analysis and represent the system 
diagramatically. These are discussed later in the book. 


A structured-walkthrough: a method for reviewing the specifications for 
various aspects of a design, is a commonly used technique for making 
sure that the design is appropriate. 


The detailed design specification is ee onto the programmers for 
software development to commence. Designers are responsible for 
guiding the at ina through the design specifications. 
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1.4.5. Development of Software 


The “Design Specification” contains program specifications as one of its 
topics. This is used by programmers for the development of software. In 
this stage, the actual coding/writing of the programs is done. In some 
firms, separate groups of programmers do the programming whereas 
other firms employ analyst-programmers who do analysis and design as 
well as code programs. Programmers are also responsible for 
documenting the program including comments that explain both how 
and why a certain procedure was coded in a specific way. Programs are 
individually tested using some test/dummy data. Documentation is also 
essential to test the program and carry out maintenance once the 
application has been installed. 


This activity of the systems development lifecycle produces tested 
programs. 


1.4.6. Systems Testing 


Once the programs are tested individually, then the system as a whole 
needs to be tested. During testing, the system is used experimentally to 
ensure that the software does not fail i.e. that it will run according to its 
specifications and in the way the users expect it to. Special test data 
(which should include all types of data ) is prepared as input for 
processing and the results are examined to locate unexpected results. 
In many organisations, testing is performed by persons other than those 
who wrote the original programs. Using persons who do not know how 
the programs were designed or programmed ensures more complete and 
reliable software. Various methods are available for testing. These are 
discussed later in the course. 


This phase of the SDLC produces the tested system. 
1.4.7. Systems Implementation 


In this stage, the systems analysts put the new software which has been 
tested into use. User personnel are trained and any files of data needed 
by the new system are constructed. In short, the new software is 
installed and then used. 


1.4.8. Systems Maintenance 


Once installed, the software is often used for many years. However, both 
the organisation and the users change. The environment may also 
change over a period of time. Therefore the software has to be 
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maintained i.e. modifications and changes will be made'to the_software, 
files or procedures to meet the users requirements. 


1.5 Fact Finding Techniques 


As already seen Data collection is an important part of ‘analysis. This 
can be accomplished using fact-finding techniques to gather information 
from the users. The following fact-finding techniques are used for this 
purpose . Each of them have been discussed briefly :- 


° Interviews 
* Questionnaires 


¢ Record inspections (on- site review) MT 


¢ Observation 


Normally more than one of these techniques are used to ensure 
accurate investigation. Important points of each of these techniques are 
listed below. 


1. Interviews 


Analysts use interviews for Collection of information from individuals or 
groups who are generally current users of the existing system or 
potential users of the proposed system. They maybe managers or 
employees who provide data for the proposed system or who will be 
affected by it. 


Interviews is a time consuming method. It is the best source of 
qualitative information (opinions, policies, and subjective descriptions of 
activities and problems). 


Interviews allow analysts to discover areas of misunderstanding; 
unrealistic expectations and even indications of resistance to the 
proposed system. 

Interviews could be: | 


1. Structured 
Structured uses standardised questions. These could be:- 
a. Open response format 
Here the questions are answered in‘ones own words. 
b. Close response format 
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Here set of prescribed answers are used. 


2. Unstructured 

Here the questions are worded to suit respondent may produce 
information about areas overlooked and which could be 
important. 


2. Questionnaires 


The use of questionnaires allows collection of data from large number of 
persons. 


Standardised question formats yield more reliable data where the 
responses could be more honest. In this method the Analyst cannot 
observe reactions or expressions of respondents. 


Questionnaires could be Open-ended OR Closed questionnaires. Open- 
ended questionnaires are used to learn feelings, opinions, general 
experiences on process detail or problem. S 


Closed questionnaires offers specific responses which have to be 
selected. 


Questionnaires need to be printed and hence its a costly method. 
3. Record Review 


Many kinds of Records and reports provide valuable information about 
organisation and operations. Records include written policy manuals, 
regulations, standard operation procedures used by the organisation as 
a guide. These do not show actual activities, where decision making 
power lies or how tasks are performed. They Help in understanding the 
system. While observing the current reports one should scrutinise the 
data present in them. 


4. Observation 


This method helps to obtain first hand information on how activities are 
being carried out. It is useful when analysts needs to observe how 
processes are carried out, and whether specified steps are actually 
followed. One should know what to look for and how to assess the 
significance of what.is observed. 


te 
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1.6 Job Of A Systems Analyst 


We have briefly discussed the various phases of the System 
Development Life Cycle. A number of people are involved in the process 
at different stages - the systems analyst, designers, programmers, users, 
operators. Systems analysts and design is carried out by a systems 
analyst. j 


A Systems Analyst studies the problems and needs of an Giganisation to 
determine how people, method, and computer technology can best 
accomplish improvements for the business. When computer technology 
is used, the analyst is responsible for the efficient capture of data from 
its business source, the flow of that data to the computer, and the timely 
information back to business users. 


1.6.1 Qualities of Systems Analysts 


Proficiency in systems analysis and design comes with experience and 
time. However, there are some essential qualities that a Systems 
Analysts should posses: 


° The analyst is a problem solver. He/she views the analysis of 
problems as a challenge and outputs a workable solution. 


e The Analyst should be capable of tackling situations at hand 
through skilful application of tools, eopniduss and experience. . 


° The Analyst must be a good COPA UICALON capable of. relating- 
meaningfully to other people over a length of time, to’gain : 
information requirements from users and to communicate well 
with programmera; ; 

o ` The Analyst needa PNE Ca mnten experience to! program 

.. and to understand the capaniliice of computers... ; 


i í ry nah “UNO <í 


Succeas ofa E depens iaepahs on S well it is aa a and 
interpreted. Thus, communicating and dealing with people is a 
very Imponert part a the eget Anena Job. 


a 
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1.7 Members Of The Systems Development Team 


Traditionally Systems Analyst and Systems designers served as 
communication links between the programmers and the 
user/management group. Analysts helped users specify: their 
information requirements. Designers turned those requirements into 
technical specifications and programmers turned the technical 
specifications into working programs for the user/management group. 


Systems 
Requi pxcuneeannennesssnnnsssn seams 


a Analyst _ Objectives: Designer Specifications Programmer ~ 
$ H i H H 


{Management 
L Group 


H H H H 
Lossesesasasasseasuesssuusses Eaeeaesaremnneranarennaannn -= Loreeereeeee renee meee eera m 


Tested System | Tested program code 


Figure 1.2 Shows The Link Between The Development Team 


1.8 Introduction to Software Engineering 


Software Engineering is a field of computer science that deals with the 
building of large complex systems. These systems are not built by a 
single person; they are built by a team or several teams of software 


engineers. 


Software Engineering is the application of science and 
mathematics by which the capabilities of computer equipment are 
made useful to man via computer programs, procedures and 
associated. 


This definition of software engineering contains two key points. Firstly, 
software includes a good deal more than just computer programs. Thus, 
learning to be a good software engineer means a good deal more than 
learning how to generate computer programs. It also involves learning 
the skills to produce good documentation, data bases, and operational 
procedures for computer systems. The “mathematics and science” of 
software engineering is to provide methodologies for developing 
software as close to the scientific method as possible. IE 


Secondly, the software products must be useful to man. The phrase 
«useful to man” emphases the needs of the user and the software’s 
interface with the user. Software engineers must apply their skills and 
judgment to the job of developing appropriate set of specifications, and 
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ensuring that the resulting software does indeed make the computer 
equipment perform functions useful to society, Also for something to be 
useful to pcople, it must satisfy a human need at a cost that society can 
afford. 


The basic goal of software engineering is to produce high quality 
software at low cost. There are various techniques available to estimate 
cost and also measure the quality of a software product. 


A software system is a component of a much larger system. The software 
engineering activity is a part of the design of a larger system. There are 
various approaches to the development of large systems. These are 
discussed in the next section. 


1.9 Computer Aided Software Engineering (CASE) 


Software development and maintenance is a mammoth task especially if 
done manually. CASE: is the technology for automating software 
development and maintenance. The basic idea of CASE is to provide a 
set of well-integrated, labour saving tools and automating all phases of 
the software development life cycle. Hence, CASE is a tool for software 
engineering. CASE tools are software tools that support activities such 
as’ analysis, ‘design, project management and maintenance. There are 
CASE tools available today that support most of the methodologies. 
Examples of CASE’ tools are EXCELERATOR, Information Engmocuig 
Workbench (IEW), Turbo Analyst. 


1.10 Software Methodologies: 


The “waterfall life cycle” which! was developed’ in the late 1960s i is one of 
the commonly practiced approach to software development till tte early 
1990s. The waterfall life cycle is illustrated below 
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Figure 1.3 The Waterfall life cycle 


Today we have number of other approaches and methodologies being 
proposed by various people. 


Method vs. Methodology 


With the above model as an example, we can discuss the difference 
between the terms “method”, “methodology”, and “life cycle”. Different 
organisations use these terms differently and there are -various 
interpretations of these words. 


Methodology - is a step-by-step plan for achieving some desired result. 
A software methodology usually identifies the major activities (for 
example, analysis, design, coding, and testing) to be carried out and 
indicates which people (users, managers, technicians) should be 
involved in each activity and what role they play.. Methodologies often 
describe entry criteria, exit criteria and checkpoints for each of the 
activities/stages. The term Life-Cycle can be used synonymously with 
the term Methodology. 


Method - is a step-by-step technical approach for performing one or 
more of the major activities identified in the an overall methodology. 
Thus, “structured analysis” is a method for carrying out the analysis 
phase of a project, while “object-oriented design” is a method for 
performing the design phase. (These different approaches are discussed 
later). : 


in many cases method and methodology go hand in hand and can be 
used in combination also. Like the waterfall life cycle is completely 
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method independent in the sense that it can be used with an 
information engineering method, a structured analysis/ design methad 
or an object-oriented analysis/design method. Hence, it is a 
misconception to say that an organisation cannot follow the object- 
oriented approach because it is following the waterfall life cycle. As is 
commonly misunderstood, the waterfall approach is not opposed to any 
method. : 


Popular Methodologies 


The most popular methodologies in use today are based on structures 
techniques or information engineering techniques. “Object-oriented 
techniques have of late attracted a great deal of attention and may 
become the dominant methodology by the end of this decade. 


Structured Methodologies 


Structured techniques made their first appearance in the late 1960s, 
with the introduction of structured programming. Structured design and 
structured analysis techniques were proposed later in the 1970s. These 
techniques are best suited for process-oriented systems i.e. they are. 
driven by the functionality (processes): of the system rather than by the 
data used in the system. It is more a function-oriented methodology 
than a data-oriented methodology. Structured analysis and design tools 
were originally characterised by two graphical modeling tools (data flow 
diagrams and structure charts) that emphasised the functions 
performed by a system. Additional components included data 
- dictionaries, process specifications and later on incorporated entity- 
relationship diagrams and state-transition diagrams tovhelp the software 
engineer model the data and time-dependent behaviour of a system. The 
methodology aspect of structured techniques was first described by 
DeMarco as a progression from a “current physical”? model to “new 
logical” model. 


The Yourdon, DeMarco and Gane-Sarson methodologies follow the 
structured analysis and structured design approach. Most of the CASE 
vendors based their automated tools on the methodology described in 
the books written by Yourdon & Constantine, DeMarco and Gane & 
Sarson. 


Jackson’s Data Design Methodology 
In the Jackson approach, the input and output data structures are - 


defined first which are then integrated to define the processes. The 
emphasis in this methodology is on data rather than process. : 
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Warnier-Orr Design Methodology 


This is a data oriented approach where the focus is on system output. 
The software engineer first defines the outputs required by the system 
and then works backwards and develops the system model. This system 
model will define all the inputs required and the processes required to 
transform them. 


Information Engineering (IE) Methodologies 


The IE methodologies reverse the emphasis : data plays the dominant 
role and functions play a subordinate role. This has been promoted by 
people like James Martin and CASE vendors like Texas Instruments, 
KnowledgeWare etc. This methodology includes business 
functions/entity-type matrices to show relationships within the 
enterprise and entities they use or modify and include diagrams like 
E/R diagrams, hierarchy diagrams etc. e ‘ 


More important than the emphasis on data is'the emphasis on the level 
of the model in IE methodologies. While structured methodologies can 
be used to model entire enterprises, in the majority of cases they are 
used to model individual programs or systems. IE is perceived as a 
higher-level methodology that is intended to first model the 
enterprise/organisation and then model the individual systems that 
constitute the organisation. The idea is not to study only a particular 
system but the organisation as a whole which ‘constitutes a number of 
subsystems. Information is the thread» binding all the different 
functions/subsystems and hence it forms the basis for analysing the 
business needs, objectives and strategies. An organisational view is 
taken and a model built which shows the relationships of these various 
elements (Entity-Relationship model). This model when further 
decomposed will give details of the individual systems and the processes 
within them. Thus, IE is becoming gradually more popular as 
organisations are looking at enterprise wide solutions and total 
methodologies: - 5 


- 


Object-Oriented Methodologies 


Object-oriented programming technologies existed in 1960s (SIMULA 
language), but have gained more popularity recently and have been 
emphasised with object-oriented analysis and design techniques 
proposed by Grady Booch, Peter Coad and Edward Yourdon. The recent 
shift in interest to an object-oriented approach is a result of a gradual 
shift in priorities and technologies. Some of the key factors are : 
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The underlying concepts of an object-oriented approach have matured 
from issues of coding to issues of analysis and design. 


The underlying technology for building systems has become much more 
powerful. Like it was difficult to think about coding in an object-oriented 
fashion when the language of choice was COBOL, FORTRAN, or G; it has 
become easier with C++, Objective-C, Smalltalk and Ada. 


The systems we build today are different than they were 10 or 20 years 
ago. In every respect, they are larger and more complex; ‘they are also 
more volatile and subject to constant change. We find that today’s on- 
line, interactive systems devote much more attention to the user 
interface than the text-oriented batch processing systems. Almost 75% 
of the code in modern systems is concerned with user interfaces and 
this is particularly evident with the GUIs available today. With systems 
being subject to constant change," reusing components ‘of existing 
systems and building newer systems'‘has become a necessity. An object- 
oriented approach to such systems (from analysis through design and 
into coding) ‘is a more natural way of dealing with such’ user-oriented 
systems. Systems built today are more “data-oriented” than’ systems 
built earlier. Hence, modeling; the data has become a eana prione 


Which is the most suitable methodology?’ ‘ nie 


Software engineers are‘ constantly faced with the dilemma of‘which 
methodology to use for which system. The’ ‘solution ‘is to use the 
methodology depending‘on the application/system int question. The type 
and requirements of the application will “dictate which method is best 
suited for that system. For example, the Yourdon method of structured 
techniques is very effectively used for a eee commercial 
applications like payroll, accounting etc. : 


Exercise -3 


Ans: 1) Operational, Technical and Economical s spernenn eve 
2) Intervicw, Questiorinaires, Record review and Observation 
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3) Functional Specification 
4) User/ management, Systems analyst, Systems designer and Programmer. 
5) communicating and dealing with peuple is a very important part of the Systems Analysts’ job. 


Summary 
In this chapter we have learnt the follaqwing:- 


+ A system is simply a set of components that interacts to 
accomplish some purpose. 


+ An information system is the means by which data flows from one 
person of department to another. 


+ System’s analysis and design is a series of processes 
systematically undertaken to improve a husiness through the use of 
computerised information systems. A largu part of system's analysis 
and design involves working with current and eventual users of 
information systems. 


Analysis specifies ‘what’ the system shculd do. 
Design states ‘how’ to accomplish the abjective. 


e The various categories of information systems are : 
+ . Data processing systems 
+ Management information systems (MIS) 
+ Decision Support Systems ‘ 
> -Expert Systems 


e Systems development life cycle is a phased approach to analysis and 
design that holds that systems are best developed through use of a 
‘specific cycle of analyst and user activities. 


“& systéms develegsrient life cycle method consists of the following 
; ivities: aes Fay 


sae 


7 Ppeliminary investigation (feasibility study) 


1.: is 
2. peiin of Systems requirements 

3. » Mokign of the system k ; a 
4.: Beveloprent of software er 
5. Systems testing hei, 
6. Systems implementation 
7. Systems Maintenance 
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Data collection being an important part of analysis, should 
accomplished by fact-finding techniques. They are as follows : 


> Interviews: structured or unstructured 


+> Questionnaires 
+ Record inspections E 
+ Observation = 
u b X D ; s P x r 
gi; faa a He TAS i Bry Ff he 
a 
N 
B 
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Remember that fime is money 


- Benjamin Franklin 
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Chapter 2 
Structured Analysis 


At the end of this session, you will be able to: 
> Define structured analysis and its components 


> Define data flow analysis and understand the tools used for data 
flow strategy 


> Draw DFDs - context diagrams and levelling of DFDs 
> Define Data Dictionary, know its importance and what it records 


>: Know what is prototyping 


2.0 Introduction 


This chapter focuses on Structured Analysis. Apart from being 
introduced to “what” is Structured. analysis, you will also learn about its 
components. You will be given an idea of Data Flow Analysis, Data Flow 
Strategy and Data Dictionary’s. These various tools used for structured 
Analysis are explained in detail. You will be taught how to draw-a Data 
Flow Diagram, the various symbols used in it, and also what is a data 
dictionary, its importance and what it records. Besides all this, it 
introduces to Prototyping. 


2.1 What is Structured Analysis ? 


Structured Analysis is’ a development method for the Analysis of 
existing, manual or automated systems, leading to the development of 
specifications (i.e. Design) for a new or modified system. Structured 
Analysis allows the analyst to learn about a system or a process in a 
manageable and logical way. ; 


The objectives in Structured Analysis is to completely understand the 
current system, from which requirements are determined, which 
become the basis for a new or modified system. Fully understanding 
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large, complex systems maybe difficult, but, structured analysis 
development method is aimed at overcoming this difficulty through its 
components which are described later in this chapter. 


Structured Analysis came about during the late 1970s as a method of 
communicating more effectively with users during the entire system 
development life cycle. If structured analysis is done in a proper 
manner, it allows the systems analysts to develop systems that are 
wanted by the users and that can be used by them in an effective 
manner. The aim of structured analysis is to clearly define WHAT a 
systems requirements are. 


2.2 Components of Structured Analysis 


Structured Analysis uses the following components :- 
1. Graphic Symbols 


These include icons and Data flow diagrams. Instead of words, 
structured analysis uses symbols or icons to create a graphic m ‘el of 
the system. Graphic models show details of the system. 


e Icons are pictorial representations of entities described by the 
data. Properly selected icons communicate information 
immediately. Icons eliminate the necessity for users to learn 
abbreviations, notations, or special nomenclature. 


e Data Flow Diagrams is very important graphic tool which is used 
to describe and analyse the movement of data through a system - 
manual or automated. The model of the system is termed as data 


flow diagram. 
2. Data Dictionary 
The Data Dictionary stores details and descriptions of all data used in a 
system. It is an organised listing of all the data elements that are 
pertinent to the system. 
3. Procedures and Process Description 
This is the third: major tool of structured» analysis. The purpose of 


process description is to allow the analyst to describe the business 
policy represented by each of the‘bottom level bubbles in the bottom 
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level DFDs. These can be written in a variety of forms such as - 
structured English, Decision trees, Decision tables, action diagrams. 
These are discussed later. 

4. Rules 

These are standards for describing and documenting the ‘system 


correctly and completely. Good documentation .will provide an 
explanation of how a system operates. ; > 


2.3 Data Flow Analysis 
2.3.1 What is Data Flow Analysis 
Systems analysis is basically centred around 
> What EE males up 5 en 
> What data “ne used Fes each process of the system © best 
> What data is Fore : t í | 


> What data enter and leave the system 


The emphasis is clearly.on Data Analysis. ° 


Following the flow of data through business processes is Data Flow 
Analysis. While handling transactions and completing‘ tasks, data are’ 
input, processed, stored, retrieved, used, changed and output. Data flow 
analysis studies the use of data in each activity. G orita e 


These findings are documented in ‘ 


Data flow diagrams, which graphically show the relation between. 
= processes and data. Tile Gig 


: Data dictionary, which formally describe the systems data and 
where they are used: si =: no si ap, S EEA : 
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Data flow analysis maybe thought of as viewing the activities of a system 
from the viewpoint of the data :- 


e Where they originate ? 
e How they are used or changed ? 


e Where they go including the stops along the way from their origin 
to their destination. 


2.3.2 Tools of Data Flow Strategy 


The components of Data flow strategy are used for both systems 
requirement (analysis) as well as systems design. Data flow strategy 
makes use of the following tools :- 


1. Data Flow Diagram 


Through the use of a structured analysis technique called data flow 
diagram, the system analyst is able to put together a ‘graphical 
representation of data processes through the organisation. The data flow 
approach emphasises the logic underlying the system. By using 

combinations of only four symbols, the analyst is able to create a 

pictorial depiction of processes that eventually can ‘provide solid system 

documentation. 


2. Data Dictionary 


All definitions of elements in the system are described in detail in a 
data dictionary. The data dictionary is a reference work of data about 
data i.e. metadata, complied by the analyst to guide‘them through 
analysis and design-. 


3. Data Structure Diagram 


Although historically, systems analysts have thought of data in the form 
of data items, records, and files, experience has shown that a broader 
framework is needed. Data structure: diagrams, is°a useful! toor for 
developing this framework. 


Data Structure Diagrams. are graphic tools that show’ theé'‘logical ‘data 
structure requirements of an information systems application, “Each 
data item either identifies the entities or describes an important 
attribute. Data structure diagrams organise the data. 
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4. Structure Chart 


This is a design tool that visually displays the relationships between 

program modules. It shows which. modules within the system interact 

and also graphically depicts the data that are transmitted between | 
various modules. Structure charts are developed before the start of 

coding programs. They don’t express procedural logic nor do they 

describe the actual physical interface between processing functions. 

They identify the data passes existing between individual modules that 

interact with one another.. : 


Data . structure diagrams and structures charts are: deålt: with in 
subsequent chapters. 


2.4 Data Flow Diagrams 


Data flow diagram is a graphic tool. It is used to describe and analyse 
the movement of data through a system - manual or automated. They 
focus on the data flowing into the system, between processes and in and 
out of data stores. This is a central tool and the basis from which other 
components are developed. ‘The system models are termed as Data Flow 
diagrams (DFD). : 


Developing a description of the system using structured analysis follows 
a top-down process. A full description of a system actually consists of a 
set of DFDs, which comprises of various levels. An initial overview 
model is exploded into more detailed lower level diagrams that show 
additional features of the system. Further each process can be broken 
down into a more detailed DFD. This occurs Tepeatedly until Ț 
sufficient detail (lowest level) is’ described to allow the analyst to fully 
understand that portion of the system. The various levels of DFDs are 
shown later on in this section. 5 = 


2.4.1 Types Of Data Flow Diagrams 


DFDs are of two types. 


1. Physical DFDs 


Structured analysis states that the current system should be first 
understood clearly. -The physical DFD is a model of the current 
system and is used to ensure that the current system has been clearly 


CEF 
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understood. Physical DFDs show actual devices, departments, veople 
etc. involved in the current system. 


2. Logical DFDs 

Logical DFDs are the models of the proposed system. They should 
clearly show the requirements on which the’new system should be 
built. Later during design activity this is taken as the basis for drawing 
the systems structure charts. 

Both Physical and | Logical DFDs support a top-down approach to systems 
analysis. For this purpose, Analysts begin by developing a’ general 
understanding of the system and gradually explode components in 


greater detail. This is achieved through the Context diagram, First Level 


DFD, Second level DFD. These concepts are explained in the following 
sections. 


2.4.2 Drawing Data Flow Diagrams 
2.4.2.1 Notation 


DFDs are quite easy to read and understand. There are two alternative 
but equivalent symbol sets : ; 


1. Yourdon symbol set 
2. Gane - Sarson symbol set. 
It is suggested that you do not mix and match symbol sets. 
Four simple notations are sufficient to complete.a DFD. They are: 
1. Data Flow 3 
2. Process 
3. External entities 


4. Data Store 
A brief description of each of these notations are given. 
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1. Data Flow we, 


Data in a system move in a specific direction that is from origin to 
destination. The data flow is a ‘packet’ of data indicating the movement 
of data within the system. Data flows must be inputs to or outputs from 
processes. They must contain data and all data flows should be labelled 
indicating what data is flowing. If the data flow is showing an input then 
the arrow should point towards the process, but incase the data flow is 
showing an output then the arrow should point away from the process. 


-— — 


Yourdon Gane - Sarson 
e.g. of Data flow : Month’s Transactions details, New Employee Details. 
2. Process 


The emphasis in any DFD is placed on processing. Processes transform 
inputs into outputs. They are work or actions that are-peiformed by 
people, machines, or computers on incoming data flows to produce 
outgoing data flows. They can be performed by people, departments, 
robots, machines, or computers. The details of the processing that is the 
logic or procedures are not shown in a DFD. The data flow leaving a 
process is always labelled differently from the one entering it. Each 
process should be given a meaningful name. 


Yourdon Gane - Sarson 
e.g. of Process: Calculate Net Pay, Preparation of payslips etc. 
3. External Entities 


External entities are organisations, other information systems, 

departments or people which represent a source or destination of 

transactions or data. When the system we are considering accepts data 

from another system or provides data to it, that other system is the 

external entity. By designating something or some system as an 
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external entity, we are implying that it is outside the boundary of the 
system we are considering. 


External entity represents any entity that supplies or receives 
information from the system but is not a part of the system. Each entity 
is labelled with a appropriate name. Although it interacts with the 
system, it is considered as external to the boundaries of the system. 


Examples of entities in our case study are : New employee - from whom 
we obtain the employee’s data; Departments - from where attendance 
and OT data are obtained; Accounts department - provides us with the 
advance salary data and this entity gets the accounts statement from 
the system. 


g B 


Yourdon Gane - Sarson 


4. Data Store 


Data stores could be thought of as the ‘memory’ of the system. Any place 
that data accumulates is a data store. Data flow diagrams,do not specify 
the type of physical storage i.e. tape, disk etc. The data in a data store, 
are ‘stored or referenced by a process in the system. They represent 
computerised or non-computerised devices. 


A data store must have atleast one data flow pointing towards it, or one 
away from it. The data store must have a label which is placed between 
the two parallel lines. The labels of data stores must be nouns and must 
clearly identify what the data store contains as a class of objects. 


E.g. of data stores in our case study : Employee master file; Transaction 
file; Payslip file, employee master register. 


[a | 


Yourdon Gane - Sarson 
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Ans: 1) Graphic symbols -( icons, DFD’s), Data dictionary, Procedure & Process description, Rules 
2)) DFD:- Graphically show the flow of data throughout the system. 
Data Dictionary : - They formally describe the system data and where thoy arc agre 
3) DFD, Data dictionary, Data structures and Structure ‘charts 
4) Data flow, Process, External entities, and Data stores 


2.4. 2.2 Steps Involved In Develdniag Data, row Disgrama For 
~The Proposed System sro 


It is important to remember that data flow diagrams can and should be 


drawn systematically. We will now summarise the „steps involved in- 
successfully completing data flow amn 


curr ria > 
Ui 
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DEVELOPING DATA FLOW DIAGRAMS 


1. Develop the data flow diagram using the top-down approach. 


a. Make a list of external entities, data flows, processes, 
and datastores. This determines the boundary of the 
system you are describing. 


b. Draw a basic data flow diagram - Context Diagram, 


showing just the overview. This is done by identifying 
the main process of the system. 


2. Fill in the details - Exploding the context diagram. 


a. Add more detail for steps within each process. 


b. Add exceptions wherever necessary. 


3. Deriving the logical view from the physical view. 


Step 1. Using Top-Down Approach 


You can begin a data flow diagram by first making a list, consisting of 
four categories : 


+ external entities 
> data flows 

> process 

» data stores 


This list helps determine the boundaries of the system you will be 
describing. Once a basic list of data elements has been complied, you 
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t: 


can begin by drawing a context diagram. This.is done by identifying the 
main process of the system. Each diagram should be self-contained on a 
single sheet of paper. : 


The initial context diagram should be an overview including basic 
inputs, processes, and outputs. This will be the most general diagram, 
really a bird’s eye view of data movement in the system. This is called 
taking a “top-down approach” to diagramming data movement. With a 
top-down approach, the diagrams move from general to specific. While 
the first diagram helps the systems analyst grasp basic data movement, 
its general nature limits its usefulness. 


Physical Context Diagram For Payroll Monitoring System 


The DFD showing the general i.e. top layer of the system is called the 
‘Context diagram’ : ; 


Fig 2.1 


iama n 


_ Figure 2.1 shows the Physical Context Diagram which describes the 
. Payroll monitoring system at avery general (top) level. ©. 00 7 


ALY 
3 
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+ The context diagram consists of only one process, data flows and 
entities. The main process of the system needs to be identified. 


> The single process in figure 2.1 is ‘Payroll Monitoring System’. 


+ The context diagram defines the system in study i.e. it determines 
the boundaries. 


> Each arrow, representing data flow, is labelled to show what data are 
being used. ; 


> New employee gives the new employee details and the employee’s 
bank details to the system. 


> The respective departments feed the system with the O.T details, 
attendance details and employee details which are to be updated. 


> The accounts department give the advance salary details. 


> The accounts department receives the accounts statement from the 
system. 


> The salary statement is received by the respective department. 
> The bank receives the bank statement 
> The employee receives the payslips 


> When data moves to a process ( i.e. data serves as input to the 
process) the arrow points towards the process to reflect the input. 

> When the process produces data, the arrow points away from the 
process reflecting the output. sae i 


Step 2. Filling In The Details - Exploding The Context Diagram 


Second, fill in the data flow diagrams by adding more details to each of 
the processes. More detail is achievable through using a process called 

“exploding the diagrams”. (Going from higher level to lower is called 
‘exploding’ a data flow diagram. ).When the first diagram is made, inputs 

and outputs are specified and these remain constant throughout all of 
the following diagrams. 


The original ‘diagram ds exploded into close-ups of three to nine 
processes ( in our example we have exploded into five processes). New 
ee e a 


SD eee a2 
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data stores and new data flows are added in lower levels. The effect is 
that of using a magnifying glass to the original data flow diagram. Each 
diagram should ideally use only a single sheet of paper. By exploding 
DFDs into subprocesses, the systems analyst begins to fill in the details 
about data movement. 


Because the nature of.complexity of systems vary, one cannot fix a 
specific number of levels of the DFD. Incase the DFDs are over 
complexed they cause difficulty in understanding them. On the other 
hand if they are under exploded, errors of omission could occur. You 
should go as far as necessary to understand the details of the system 
and the way it functions. 


Care should be taken to verify all aspects with knowledgeable users by 
conducting a walk through with them. Changes need to be incorporated 
after getting users input. 


Developing the First Level Physical Data Flow Diagram For Our 
Payroll Monitoring System 


The description of the payroll monitoring in the context diagram 
requires more details. We now have -to describe the system as we 
understand it at level 1. 
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PT 
FIRST LEVEL PHYSICAL DFD FOR PAYROLL CALCULATION OF SALES DE 


| Emp. f 

| 

—_—_—_—_ee 

i Sales | = updates emp. 
Emp. Details to be updated Regst. Of sales 


dept. 


Transaction list of 
Sales dept. 


Employee Register 
Of Sales Dept. 

Calculate Net 
Pay of Sales 


dept. 


[Sales Salar Summary Statement 


i Dept. ; salary a 
4 | ~ statement of 


co Bales.dept. 
| ate zs 
Bak {© 
ee 
test Fig. 2.2 
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Figure 2.2 shows the First Level Physical. Data Flow Diagram of the 
payroll calculation of the Sales department of ABC Co. Ltd. 


The same is applicable for the other two departments of the company. 
(only the department name will vary). As can be seen his level of the 
DFD contains five processes. 


The following is seen in the DFD. 


> 


The New Employee Data from the filled appointment form is entered 
into the respective department’s employee register by the 
administration clerk. 


‘Administration clerk makes changea in AbD employee register 
wherever required. 


The month’s transaction list is written out after the pevne gether : 
the following details. 


* Month’s attendance details are obtained from (e tendane 
register. 


* Day-wise O.T data obtained from the O.T register / 


*- Advance salary details obtained from the advance salary vouchers 
obtained form, the accounts department. ` 


Now using this transaction list Av the details from the employee 
register the payroll of each employee is calculated. The payroll 
statement of the month is prepared using the calculated figures. 


The payroll statement’ forms the basis for typing out the payslips 
and the bank statement and salary statement. 


The payslips are handed over to the employees of the respective 
departments and the bank statement i is sent to the banks. ` 


BoT Structured Analysis © 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Second Level Data Ficw Diagram 


We have just seen and discussed the First Level Physical DFD. We need 
more detail to understand the system better. The processes “obtaining 
month’s transaction” and “Calculation” need more explanation. . From 
that we learn that the processes need to be exploded in the sense, need 


for more detail is required to get a clearer idea of the system. We need to 
draw lower levels of the DFD to obtain this. 


SECOND LEVEL DFD FOR OBTAINING MONTH'S TRANSACTIONS OF SALES DEPT, 


Days Absent Employee-wise 


| days absent list 


Transaction list of 
Sales dept. 


Fig. 2.3 
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Fig 2.3 shows the Second Level DFD for ‘obtaining month’s transaction’ 
process for payroll calculation. From this we can gather :- 


> That the administration ‘clerk gets the attendance register from 
the y 
respective department and'calculates the days absent of each 
employee. i 


Yy 


He also gets the day-wise O.T- register and totals the O.T hours of 
each employee. - t 

> The accounts department supplies the admin. clerk with the 
advance salary taken details through vouchers. 


> Having got this he makes. out a month’s transaction list 
containing days absent (if any), total O.T hours and advance 
salary taken for each employce: 
er ea 
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Fig. 2.4 Second Level DFD for ‘Calculation’ process of the payroli system 
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From figure 2.4 we gather:- 


> That the administration clerk checks the employes register and 
by-passes all exit cases. 


> For each non-exit case he checks the: transaction list fon any 
transactions of that particular employee. 


> He then uses the data present in the employee register and the 
transaction list (if data for the employee present) to calculate the 
payroll for the month. The month’s payable gam is: rhus obtained 
and'stored in pie payroll statement: os 


All activities, data flows and! data‘stores in this v lowertiewel view of the 
system must be included within the previous DFD. shi 209 


a rho) At 


In general, we should be Certain of the following’ inn 


> All:data‘flows that appeared on the previous diagram “explaining 
the process are included in the lower level diagram. ~ ~ 


> New data flows and data stores are added if they are used 
internally in:the process to link processes introduced for the first 
time in the explosion at this level. 

> „Data flows and data stores that originate within the process 
must be shown. - 

> No entries should contradict, the description of the higher-level 


data flow diagram (if they do, one or the other is either is 
incorrect or incomplete and a change must be: introduced). 


Notice how we continue using physical details of the process: 


The clerk calculating the days absent using the attendance 
register, using the overtime register, typing of the transaction 
list, the clerk having to check the exit code and typing Of the 
payroll statement and the payslips. 
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implementation ( the users are better able to discuss the physical 
system as they know it thoroughly.) 


A logical DFD also follows a top-down process. This involves drawing the 
context diagram and exploding it to obtain the first level, second level 
and so on until all the processes mentioned are clearly understood. 


A logical DFD is derived from the phystoalis version by doing the 
following : 


> Showing the actual ‘data’ needed in a process, not documents that 
contain them. 
e.g. show ‘new emp. data’ rather than ‘appointment form’. 
> Remove routing information, that is, show the flow between 
procedures’ not between people, offices or locations. 
Remove tools and devices such as folders files etc. 
Consolidate redundant data stores. 


Remove unnecessary processes, ach as those that ao not change 
the data or data flows. 


YYY 


Figure 2.5 shows the logical Context Diagram For im Palenlation of 
the full company. - 


LOGICAL CONTEXT DIAGRAM FOR PAYROLL PROCESSING 


Fig 2.5 
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General Rules For Drawing Data Flow Diagrams 


Several basic rules that underlie all the guidelines we have discussed so 
far are also helpful in drawing useful logical DFDs. 


> Any data flow leaving a process must be based on data that are 
input to the process. i 


> All data flows are named; the name reflects the data flowing 
between processes, data stores, Sources. et? 


> Only data needed to perform the process should be an input to the 
process. 


» A process should know nothing about i.e. be independent of any 
other process in the system. It should depend only on its own input 
and output. 

> Processes are always running, they do not start or stop. 

Validation Of Data Flow Diagrams 

It is necessary to evaluate all data flow diagrams carefully to determine 

if they are correct..Errors, omissions, and inconsistencies can occur for 

several reasons, including mistakes in drawing the diagram. These 
errors may cause deficiency in the system. The following questions are 
useful in evaluating data flow diagrams: 


1. Are there any unnamed components in the data flow diagram - 
(data flows, processes, stores, inputs or outputs) ? : 


2. Are there any data stores that are input but never referenced 2j 
3. Are there any processes that do not receive input? 
4. Are there any processes that do not produce output ? 


5. Are there processes that serve multiple purposes, if a simplify them 
by exploding into multiple processes that can be better studied. 


6. Are there any data stores that are never referenced? 


7. Is the inflow of data adequate to perform the process ? 
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8. Is there excessive storage of data in a data store? 


9. Is the inflow of data into a process too much for the fap that is 
produced ? 


10. Are aliases introduced din the system alana Are they 
accounted for in, the data dictionary? 


11. Is each process independent of other processes and dependent only 
on data it receives as input? 


The analyst should assure that each process, data flow, and data store 
is defined in the data’dictionary. The entries'should contain sufficient 
detail so’ that other‘members of the project team can understand the 
definitions when they are needed. 


2.4.3 Advantages of pata Flow Diagrams 


> -These are sinple notations which are easily ease by users : 
and GE volved i in the system. 


Y 


‘Users can be involved i in the study of DFDs. 


Vv 


Users can suggest modifications of the DFD for more accuracy :' 


> Users can examine charts and pinpoint problems betore design 
work starts: ‘ 


> Avoiding mistakes early may prevent systems failure: © : 
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2.5 Data Dictionary 


The analyst should assure that each process, data flow and data store 
appearing in the logical DFD is defined in the data dictionary. The entries 
should contain sufficient detail so that other members of the project 
team can understand the definitions when they are needed. 


We will now discuss what a Data Dictionary is?, Why is it important?, 
and What it records. 


2.5.1 What Is A Data Dictionary ? 


A Data Dictionary is a catalogue - of all elements-in'a system. It:is a 
document that collects, co-ordinates, and confirms whata specific data 
terms mean to different people in the organisation. It is the basic 

reference work for finding the names and attributes of data elements 

used through out the system. These elements centre around. data and 
the way they are structured to meet user requirements and organisation 
needs. It is a must that all data elements are included in the data 

dictionary. The major elements are data flows, data stores, and 
processes. Data Dictionary stores details and descriptions of these 

elements. ; 


A well developed Data Dictionary should be able to provide.the following 
information: 


> How many characters are in a data item ( data element, field) ? 
> By what names it is referenced in the system? 
> Where it is used in the system ? 


Data flow diagrams, covered in the previous section are an 
excellent starting point for collecting data dictionary entries. 


It is important to update the data dictionary as changes occur. The 
dictionary is developed during the Data Flow Analysis and assists the 


analysts involved in determining systems requirements, however its 
contents are used during systems design as well. 
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2.5.2 Why Is A Data Dictionary Important ? 
The data dictionary is important for the following reasons:- 
1. To Manage the details : 


Both large and small systems have large quantities of data flowing 
through them. If Analysts try to remember it all, then chances are for 
important elements to be left out. Therefore the information of the data 
flow should be recorded. 


2. Communicate Meaning 


Data Dictionary assists in ensuring common meanings for system 
elements and activities. It records additional details about the data flow 
in a system so that all persons involved an quickly look up the 
descriptions of data flows, data stores or processes. ; 


3. Document System Features 


Documenting the features of an information system is the third reason 
for using Data Dictionary systems. Features include the parts or 
components and the characteristics that distinguish each. Why each 
process is performed and how often it is used is documented. 
Documenting system features produces more complete understanding. 
Once the features are articulated and recorded, all members of the 
project will have a common source for information about the system. 


4. Facilitate Analysis 


The next reason for Data Dictionary is to determine whether new 
features are needed in a system or whether changes of any type are in 
order. 


5. Locate Errors And Omissions 

The dictionary consists of information of transactions, inquiries, data, 
and capacity - this tells us a great deal about the system and allows you 
to evaluate it. 


TAS 


55 Structured Analysis 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


This information needs to be checked to ensure its completeness and 


accuracy. The dictionary is used to locate errors in the system 
descriptions such as :- 


° Conflicting data flow descriptions 
° Processes that neither receive input or generate output 
° Data stores that are never updated 


These need to be corrected. In dictionaries the process of recording the 
information will usually reveal errors. `: 


2.5.3 What Does A Data Dictionary Record ? 


All parts of an information system such as transactions, inquiries, 
reports, output files and databases depend upon data. 


The dictionary contains two types of descriptions for the data flowing 
through the system : 


* Data elements 


-* Data structures 


Data Structure 
Data element 


Figure 2.7 Data Description hierarchy 


Data Stores 
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Data Elements 


Data elements the most fundamental data level. They’are grouped 
together to make up a data structure. Other names for data element are 
field, data item or elementary item. It is the smallest unit which has 
meaning. E.g. of data elements are employee name, grade, date of 
joining etc. These are grouped together to make up the employee 
register. They are building blocks for all other data in the system. By ~“ 
themselves they are meaningless to the user. 


Data Structures 


Data structure is a set of data elements that are related to one another 
and that collectively describe a component in the system. e.g. Of Data 
structure: employee ‘register, consists of data elements such as 
employee name, date of joining, exit code, exit date, date of birth, 
department, grade and so on. 


Data Structures 


Data Elements Emp. Name, date of joining, ` 
grade, dept.,basic,DA,HRA ~" 


address, bank details etc. 
Figure 2.8 Relation of components in DFD - 


Both data flows and data stores are data structures. Another way of 
saying this is: if data structures are moving, they are called data flows. 
when data structures are at rest and not moving they are data'stores. 


All data structures are defined in a dictionary entry. They consist of 
relevant elements that describe the activity or entity being studied. 


The employee register data structure consists of the following major 
components. The data structures are broken down to their lowest level 
data items. For e.g. employee name, date of joining, exit code, exit data, 
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department, grade, basic salary, DA, HRA, Bank code, bank name, bank 
address, account no., monthly net salary earned. 


Describing Data Elements 


All entries in the data dictionary consists of a set of details describing 
the data used or produced in the system. Each item is identified by a 
data name. They have a description, alias, length and has specific 
values that are allowed for it in the system being studied. 


` Figure 2.9 shows a specimen form for recording a data element. 


Dt-of-Join DATA ELEMENT 
Short Description __This element describes the date when the employee joined the 
Orpanisati 


tion Type: A AN N D Date 
Aliases (contexts) 


ae | Nate 
Values 

eee | Typical 

| | Value _1/0%90 

| | Length 8 


Internal Representation 
MM/DD/YY 


(if more than 5 values, continue on 


reverse or give refernce to separate 
sheet ) 


Other editing information _The date type can be changed to o ther formats like 
dd/mm/yy, dd/mm etc. 


Related data structures / elements 


eS EE ee 


Fig 2.9 Specimen form for recording data elements 
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Data Names s me re dep Se Ce erin 


esata s 9h 


entire ‘systems development process. Hence it is advisable ep select 
meaningful and understandable data names. E.g. the date of joining is 
more meaningful if it is named DATE OF J OINING rather than ABCXXX. 


A common standard specifies that a data name should not exceed 30 
characters (capital letters A to Z, numbers.0 - 9, ‘and the Hyphen) and 
the data name should not contain any blanks. The date may then be 
written as DATE-OF-JOINING. z 


Data Descriptions 


system. e.g. The P AELB of DATE-OF-JOINING indicates the date on 
which the employee joined the company ( to distinguish this from his 
date of birth). Data descriptions should be written with the assumption 
that the person ‘who will be reading the’ description does not know 
anything about the’ system, They should ‘be brief, Jargon or special 
terms should be avoided and all words should be understandable to the 
reader. ` 


Aliases oa 

Different „programs or departments may use their own names for 
common data items. ‘Hence the data dictionary should include not only 
the data item’s most common name but alias for each element as well. 
Analyst must be aware of and catalogue different terms that refer to the 
same data item. This helps to avoid duplication of effort. It allows better 


Length 


During Systems design process it is important to know the amount of 
space needed for each data item. These details can be captured during 
data flow analysis. Length identifies the number of spaces (for letters, 
numbers or symbols) required. It does not specify how they are stored. 

For example - if employee name can be upto 30 characters long when 
written in the register, the data dictionary entry should show a length of 
30. 
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Data values 


In some processes, only specific data values are allowed. For example 
the department code of the employee could be a one letter code. This 
may also include a range of values. This detail should be present in the 
data dictionary description of department - data item in the following 
manner : 7 i 


RE 


Code Department. 

1 Sales 

Dee. Accounts ` 

3 Administration 


The system may later be designed so that the above codes are the only 
codes that are acceptable input. 


Another example could be the sex of the employee where the only codes 
that could be Pesan ire are. M’ or ‘F’ referring to male or female. 


In case data values are restricted toa specific range, that information 
should be present in the data dictionary. For example the employee 
number should have a three digit identification number. These details 
are important to the analysts later, when they design ‘systems controls. 
They will want to be sure that the system treats a four-digit employee 
number as an crror. 


Recording Data Descriptions 


A complete explanation of all elements in the DFD includes a 
description of each data flow, data store and process. 


Describing Data Flows _ 


Data flows are data structures in motion. ‘The contents ofa data flow are 


expressed by defining the names of the data structure that pass abng 
it. 


It consists of : 


` 


* The source of the data flow 

* The destination — 

* The volumes of each data structure or transaction 

e The present physical implementation of the data flow 


eee eee 
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A simple form of Data Flow is shown in figure 2.10 


New Emp details DATA FLOW 


Source ref: Description : Employee. 


Destn. Ref: Description : : Employee Register 


Expanded description : Eiye details like: Name, date of j joinng, 
dept, grade; salary details, bank details are entered into the 


emp loyee register 


Included data structures : Volume Information 
Employee register 
Volume i increases as. cr 
when employee joins. Does 
not decrease when employee 
exits, as the record is not 
deleted.: (Exit flag is inserted) 


Fig 2.10 Specimen form for recording data flow 


Fig:2.10 i 


Describing Data Stores quit tis Ja penton 


As mentioned earlier a data store is a data structure “at rest! The’ 
contents of each data store is described in terms of data structures 
found in it. It is also made up of the data flows that are input and those 
that are output from it. While describing the physical organisation of the 
data store, the details of primary” key, secondary key should be 
included. i da 
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A simple form is shown in figure 2.11 


Transaction List DATA STORE REF : 
Description : Month’s Tranasction details-.---- -- -> 
Data flows in: Data flows out 


Overtime , attendance and _ Consolidated transaction ‘of the month — 
advance salary details 


Contents : Immediate access analysis is to be found in: 


Employee number, ° 
Transaction code 
Transaction value 


Physical organisation : Sales Department 


` Fig 2.11 Specimen form for recording data store 


~ 


Describing Processes gis 


The logic of processes are documented in various ways such as decision 
trees, decision tables, and structured English. The full detailed 
description of the logic of a process cannot be included in the data 
dictionary at all times. z ; 


What is included in the data efonary,! to describe a process is: 


«i+  ¢ Inputs and outputs of the process 
e Logic is summarised = 
e Reference to the place in the Rnecanel specification. 
documentation where the logic is explained. 
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Figure 2.12 shows the specimen form for recording process. 


Description : Maintain Master Employee Pay Details 


New Employes For new apoye 
details required details need to be employee master 
bank details entered. A new record is | file 
written. 
Current employes For. old employees, details 
details to be chariged are updated  ° 
to be updated ; 


Physical ref : 


Full details of this logic can be found in : location Wane you may list 
the entire SMe 8 in derai 


Fig 2. 72 Specimen form for recording process 


Figure 2.12 
The above form should be filled keeping the following rules in mid? 


* The name of the process mentioned here should be the same 
as that in the DFD. EF 


* The description of the process should. be brief: but clay 
` understandable by any person involved in the system. 


7 The logic summary, i.e. the centre column should state the 
main functions clearly and precisely. 
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Describing Glossary Entries 


In a number of applications, the user has his ‘own jargon which’ the 
analyst or other team members may not be familiar with. The data 
dictionary is a convenient place to record these glossary items. 


2.6 Introduction to Prototyping 


The systems prototype method involves the user more directlýżin the 
analysis and design experience than does the systems development life 
cycle or structured analysis method. Prototyping is very effective under 
the correct circumstances. However, it is useful only if it is employed at 
the right time and in the appropriate manner. 


What is A Prototype ? 


A prototype is a working system - not just an idea on paper - that is 
developed to test ideas and assumptions about the new system. It 
consists of working software that accepts inputs, performs calculations, 
produces printed or displayed information, or performs other 
meaningful activities. It is the first version of an information system - an 
original model. 


The design and the information produced by theisystem are evaluated 
by users. This can be effectively done only if the data are real and the 
situations live. Changes are expected as the system is used. 


The underlying principle of prototyping is : Users can point to features 
they like or dislike and so indicate short comings in an existing and 
working system more easily than they can describe them in a theoretical 
or proposed system. Experience and use produce more meaningful 
comment than analysis of charts and narrative proposals. 


Ans: l) -onc process, data flow, and entities 
2) Makc list of extemal entities, data flows; process & data stores 
Draw the context level diagram 
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Fill in the details for steps within cach process - levelling 
Derive at a logical DFD ` À A 

3) To manage détails, To communicate the meaning the document system features, facilitate analysis, 
and locate crror and omissions 

4) Data clements and Data structures 


Summary 

Structured Analysis focuses on ‘specifying what the system or 
application is required to do. Essential elements of structured analysis 
include graphic symbols, data flow diagrams and a centralised data 
dictionary. 

Data flow analysis studies the use of data in each activity. It documents 
these findings in data flow diagrams, which graphically show the 
relation between processes and data, and in data dictionaries which 
formally describes the system data and where they are used. 


ə A physical data flow diagram shows actual devices, departments, 
people etc. Involved in the current system. 


e A logical data flow diagram shows the proposed system. 
e Drawing a data flow diagram involves: 
1. Developing the DFD using the top-down approach- context 
diagram. 
2. Fill in the details - levelling 
3. Deriving the logical DFD 
e The Data flow diagram should be evaluated for correctness. 
e A data dictionary is a catalogue of all elements in a system. 
e The data dictionary is important 
> to manage the details 
to communicate meaning 


> 
> document system features 
> 


facilitate analysis 
a 
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+ locate errors and omissions. 


e A data dictionary records data elements and data structures. 
e <A prototype is a working system 


+ not just an idea on paper 


> developed to test ideas and assumptions about the new system. 


SSAD 
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Chapter 3 | 


Normalization 


At the end of this session, you will be able to: 
> Have an idea of database design 

> Define a relation 

> Know the purpose for normalization 

g > 


Understand the.steps involved for normalization. 


3.1 Database Design 


Having identified all the data in the system, it is necessary to arrive at 
the logical database design. Database Design involves designing the 
conceptual model of the database. This model is independent of the 
physical representation of data. Before actually implementing the 
database, the conceptual model is designed using various techniques. 


The requirements of all the users are taken into account to decide the 
actual data that needs to be stored in the system. Once the conceptual 
model is designed, it can then be mapped to the DBMS/RDBMS that is 
actually being used. Two of the widely used approaches are Entity- 
Relationship(E/R) Modeling and Normalization. 


The E/R model is an object-based model and is based on a perception of 
the real world that is made up of a collection of objects or entities and 
the relationships among these. E/R Modeling is generally used as a 
top-down approach for new systems. 


Normalization is a technique that is more applicable to record-based 
data models for e.g. a relational database model. Each of the processes » 
can be carried out independently to arrive at normalized 
tables(depending on how detailed the decomposition is). If E/R Modeling 
is done in detail, normalization may not be required at all. However, 


me 
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some people use the E/R diagram as an input to normalization i.e. if the 
tables derived from E/R diagrams are in the first normal form. 


In this session we will concentrate on Normalization which is an 
important step in database design, particularly for relational DBMSs. 
The relational data model, is based on a relation. When structuring data 
that is to be stored, the analyst must anticipate the need to access the 
data to meet unexpected requirements, and to reduce redundancy. 
These can be achieved through the techniques of ‘normalization’ that 
provides a systematic way of boiling data structures down to their 
simplest possible forms. 


3.1.1 What Is A Relation? 


A ‘relation’ is a two-dimensional table. It consists of ‘rows’ which 
represent records and columns which show the attributes of the entity. 
A relation is also called a file, it consists of a number of records which 
are also called a tuples. Records consists of a number of attributes 
which are also known as fields or domains. 


In order for a relational structure to be useful and manageable, the relation 
tables must first be ‘normalized’. : . 


Attributes 


Figure 3.1 shows the components of à relation. 


Some of the properties of a relation are 


e No duplication : In the sense that no two records are identical. 


e Unique key: Each relation has a unique key by which it can be 


S 
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e Order: There is no significant order of data in the table. 


Figure 3.2 shows a relation (Unnormalized form) of the employee entity.: 

In case we want the names of all the employees whose grade is 20, we 
can scan the employee relation, noting the grade. Here the unique key 
is the employee number. 3 ; 


3.2 What Is Normalization 


Normalization is a process of simplifying. the relationship between data 
elements in a record. It is the transformation of complex data stores to a 
set of smaller, stable data structures. 


Normalized data structures are simpler, “more stable and are easier to 


maintain. Normalization can therefore be defined as a process of 
simplifying the relationship between data elements in a record. 


3.3 Purpose For Normalization oer 
Normalization is carried out for the following four reasons :- 


e To structure the data so that there is no repetition of data, this 
helps in saving space. 


e To permit simple retrieval of data in response to query and 
report requests. 


e To simplify the maintenance of the data through updates, 
insertions and deletions. 


o To reduce the need to restructure or reorganize data when 
new application requirements arise. 


Ans: 1) simpler, stable and easier. 
2) two-dimensional table,rows and columns 
3)Normalized 
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3.4 Steps Of Normalization 


Systems analysts should be familiar with the steps in normalization, 
since this process can improve the quality of design for an application. 
Starting with a data store developed for a data dictionary the 
analyst normalizes a data structure in three steps. Each step involves 
an important procedure to simplify the data structure. 


It consists of basic three steps : 


1. First Normal form which decomposes all data groups into two- 
dimensional records. 


2. Second Normal Form which eliminates any relationships in 


which data elements do not fully depend on the primary key of 
the record. f 


3. Third Normal Form which eliminates any relationships that 
contain transitive dependencies. 
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- 


Step 1: Remove . qo 
LI repeating groups. - 
i | To... Fix record length 


Spencer fal Reet) °“—" Identify primary 
i First Normal | ; kaat aT] 
i Fom ij -. z RE 
| — „Step 2: Removal of eral 
lob cas ‘items which are not: 


i Second i dependent on 000 
i è Normal į primary key- 


ae =ne Te 


Step 3 : Remidval of. 
transitive dependencies j 


F ssoveoseevereresseetuseroceevrevessennresescs wen 


Figure 3.2 Steps involved in the process of normalization: 


f 
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The relation obtained from the data store such as Employee register will ` 
most likely be unnormalized. It will consist of repeating groups and 
record will not be of fixed length. 


Unnormalised Employee Record : 
E Salary | Annual Bank 
Sal. Earned | Details 


AOE DR E a) 
C A E | 


Emp. Details 

Bas Date Exit details 
Joined Cd. date 

|i [3010/1792 | 

auw] 


CESEN 
0 [oroms |] 


Figure 3.3 Unnormalised Employee Record 
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Figure 3.3 shows an unnormalized form of an employee reco this 
consists of: . 

Employee no., employee name, employee details ( devuxtiient code, 
grade, date of joining, exit code and exit date), annual salary earned 
(MMYY , net paid ); bank details (bank code, bank name, address, 
employees A/C nd) s 


Here it is clearly s seen, that the ig iB annual on aban details 
which are : Month and Year paid, net paid, are being repeated. 
Therefore this relation is not a first normal form. 


3.4.1 First Normal Korm. 


The basic. DEVO the aE: AA make ‘to such= a record 
structure is to design the record structure. so that all recordai in the file 
are of fixed length. 


A repeating group, that is, the reoccurrence of a data item or group of 
data items within a record, is'actually .another-relation.: This is removed 
from the record and treated as an additional record ‘structure, or 
relation. 

First Normal Form - Employee Record i: 


Emp.. | Salary .|-Bank Tas 
details Desa _ pat 


Aor paoro f 
STEN [| 


Annual Sal. Earned record itia oni pica a i 
rant [095-500 
aor [0395 [3600 

Siem 


fos 
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Figure 3.4 shows the normalization to first normal form for the employee 
record. ‘ OLE on ; 


As mentioned above the first normal form is carried out’ by removing the 
repeating group. In this case we remove the Annual salary earned items 
and include them in a new file or relation called Annual Salary earned 
record. Employee number is still the primary key in the employee 
record. A* combination of employee ‘number and MMYY is the 


primary key in the annual salary earned record. =: 

We thus form two record structures of fixed length: ` ovi jasia L.D.S 
Employee record consisting of: Employee no., employee name,” 
employee details ( department code; ‘grade, date of joining, ‘exit'code 
and exit: date), bank details ‘(bank code,’ bank name; address; 
employees A/C no) . girl i 


Annual salary earned record consisting of - employee no., © month 
& year(MMYY) and net paid. © èc ismo : avr orl ; 


3.4.2 Second Normal Form 


The second normal form is achieved when every: data itemi A fecord J 
that is not dependent on the primary key of'the_record._should_be - 
_ removed and used to form a separate relation. | O07 coon | I0 


The PF department ensures that only one employee in the state is 
assigned a specific PF number. This is called a one-to-one relation. The 
PF number uniquely identifies a specific employee; :an‘“‘employee is. 
associated with one and only one PF number. Thus, lif you know the 
Employee no., you can determine the PF number. This is functional 
dependency. Therefore a data item is functionally dependant if its value 
is uniquely associated with a specific data item. ` aF = 

Now consider our Employee record example. mel in} 
figure 3.4 is the first normal form. TES MEIR e a i 


Try the following test to check whether it is also & second normal form: 


In case the bank code is known, will you know the employee no.? In 
this case ‘no’, as a one-to-one relation does not exist. Because the 
bank name is dependent on bank code and not employee no, and 
because the relation between the primary key of bank code and 
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employee no. is not one-to-one, (it is not functionally dependent);we 
know that the second normal form has not been achieved. 

Therefore, an additional record structures called Bank record. As 
created as shown in fig 3.5 


Second Normal Form - Employee ‘Record $ 


Emp. | Salary . A/C.No. I.Tax 
details. sae Details 


Jacob Rego | | | SB97SI for -[ 
[A02 | SurenGupta_| | | 1970 o | | 


Annual Sal. Earned record. 


[Emp.no | MMYY | Not Paid | 
[ao fos foso 
U E E 
[Aoz [0495 [600 


Bank’Record pee, monr bidr O ae 


for [ss [Coa 
[03 [Canara [Andei 


Figure 3.5 Second Normal Form 


The three record structures that are created are : 


1. Employee record consisting- of: Employee no.; employee name, 
employee details ( department code, grade, date of joining, exit code 
and exit date), bank details (bank code, bank name, address, 
employees A/C no) . 


2. Annual salary earned record consisting of- employee no., -month 
& year{(M MYY) and. net paid... ; =} as AW opimeen nor 
3. Bank-record consistingiof-ibank code bank name end sts 
address. All the attributes.of this relation are fully dependent on 
Bank code. 


The primary key of each of the record structures are underlined. 
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3.4.3 Third Normal Form 


Third normal form is achieved when transitive dependencies are 
removed from a record design. Some of the non-key attributes are 
dependent not only on the primary key but also on a non-key attribute. 
This is referred to as a transitive dependency. 


Conversion to third normal form removes transitive dependence:. by. 


splitting the relation into two relations. Soot 
ith eee 
i A p } B Joereceeewoes 1 
. B 4 (oe 


Reason for concern. When there is a transitive d eae À 7 leting A - 
will cause deletion of B and C as well. R SAE 


F riot 


Fig. 3.6 Third Normal Fo 
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As per figure 3.6 z 
> A, B and C are three data items in a record. 
> IfC is functionally dependent on B and i 
> B is functionally dependent op. A, 
> Then C is functionally aa en on A, 


> Therefore, a transitive dependency, exists. 


The record in figure 3.5 is in Sa normal foc There are no 
transitive dependencies, so it is also in third. normal form. icv 


> > 


Ans: 1) 1. Removal of repeating groups, fixing record length, identification of primary kcy. 
2. Removal of data items which are not dependent on primary key 
3. Removal of transitive dependencies. 
2) a data item is functionally dependant if its value is uniquely associated with a 
spccific data item. 


Summary 

In this chapter we have learnt the following: 

e A relation is a two dimensional table, consisting of rows which 
represent records, and columns which represent attributes of the 


entity. 


e Normalization is the process of simplifying the relationship 
between data elements in a record. 


Normalization is carried out for four reasons which are : 


+ to structure the data 
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to permit simple retrieval of data in response to query 
to simplify the maintenance of data 


to reduce the need to restructure or reorganize data for new 
requirements. P 


The relation obtained from a data store developed for a data dictionary 


will most likely be ‘unnormalized’. The normalization process consists 
of three basic steps which are : 


1. Removal of repeating groups, fixing record length, identification of 
primary key - first normal form. 


2. Removal of data items which are not dependent on primary key - 
second normal form 


3. Removal of transitive dependencies - third normal form. 


SSAD™ ` Sa aS 
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Chapter 4 
Process Specifications l 


At the end of this session, you will be ableto: 


= Know Decision Concepts 


-> Understand Structured English and the three basic types of - 
structured statements 


Understand the characteristics of Decision Trees 
Understand the characteristics of Decision Tables 


Build Decision Tables 


Y biy y 


Identify the types of Table Entries no SIP Ake 


4.0 Introduction 


The logic’ of the’ system cannot “be documented by any ‘of the tools 
examined so far. The data dictionary contains the details of processes 
but, does not contain the logic used to convert inputs into outputs. The 
method of operation and logical procedures of each of the: bottom level 
processes found in a logical DFD need to be examined and documented 
for study. ; = shies O SESE tr 


In this chapter, we will examine tools meant for this purpose. Tools help 
analysts assemble information gathered through the-data collection 
methods discussed. This chapter covers the three tools used for 
documenting procedures and system logic. They are’ - ‘Structured 
English, Decision Trees, and Decision Tables. 


= 
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4.1 Overview 


The Systems Analyst approaching structured decisions has many 
options for documenting and analyzing them. So far we have not dealt 
with the logic used in processes. The logic for each of the bottom level 
processes found in the logical DFD need to be examined. 


The methods available for documenting and analyzing the logic or 
decisions (of a process) include : 


e Structured English 
e Decision Trees 
e Decision Tables 


Structured decisions consist of systematic methods that promote 
completeness, accuracy, and communication. ; 


Decision analysis focuses on the logic of the decisions that are made, or 
need to be made, within the organization to carry out the objectives of 
the project. 


Once all the process procedures are documented, the process 


procedures and logic should be reviewed by the users to ensure 
accuracy. : 


4.2 Decision Concepts 


When analyzing procedures and decisions, the analyst must start by 
identifying conditions and actions. When you look at a system and ask, 


What are the possibilities ? 
or 2 
What can happen ? 


then you are looking at conditions. 


There are various conditions in a procedure. When all possible 
conditions are known, the analyst must now determine what to do 
when certain conditions occur. 


———————— O 
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Actions are alternatives - the steps, activities, or procedures that one 
may decide to take for a set of conditions. Actions could be simple or 
extensive. In many procedures, analysts must consider combinations! of 
conditions and actions. 

Process can be broken into: 

e Sequence of actions 

e Selection of actions based on some conditions - 


e Repetition of actions a 


Decision Trees, Decision Tables and Structured English are tools used to 
help understand and match combination of conditions and actions. 


4.3 Structured English 
As mentioned. above there are three tools for. decision..analysis. of 
structured -decisions also called ‘Pseudocode’. One of them being 
Structured English. This method is used when the decisions are not very - 
complex. This method makes use of narrative statements to describe a 
procedure. 
Structured English specifications require the analyst to identify : 
e the conditions that occur in a process 
e the decisions that must be made when these conditions occur 


e Actions to be taken. 


| This method allows the analyst to list the steps in the order in which 
they should be taken. No symbols or formats are used. Entire procedures | 
can be stated in English- like statements. 


On the whole structured English consists of 


e Structured logic or instructions organized into nested and 
grouped procedures 


e Simple English statements such as add, multiply, move, and so 
on. 
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4.3.1 Developing Structured Statements 


Structured English uses three basic types of statements to describe a 
process: hiss 


@ Sequence Structures 
2 Decision Structures 
2 Iteration (repeating) Structures 


These work well for decision analysis. They can be carried forward into 
programming and software development. 


Statement forms of the three structures are shown in figure 4.1 


SEQUENTIAL STRUCTURE 


Action #1 
A block of instructions where no Action #2 
branching occurs. . , Action #3 


DECISION STRUCTURE 


= IF condition A is truc 
Only IF a condition is truc, THEN implement Action A 


complete the following ELSE implement Action B 
statements otherwise jump to the ELSE 


ITERATION STRUCTURE 


Blocks of statements that are 


DO WHILE there are emplo 
repeated until donc Action #1 atte 


ENDDO 


Figure 4.1 
=a SS ee 
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> Sequence Structures 


This includes a block of instructions where no branching occurs. In 
other words they are a set of actions without the existence of conditions. 


Typically, several sequence instructions are used together to describe a 
process. 


Example : TA 
Process to update a particular employee record as he has resigned. 


1. Get particular employee record 

2. Enter ‘1’ in Exit code data element 
3. Enter date of resigning in exit date. 
4. End of job 3 


This simple example shows a sequence of four steps. Note that none of 
the steps contain ‘a decision or any condition that determines whether 
the steps are taken. ; 


The steps are carried out in order. In sequence structures, steps are 
always carried out, one after the other. The four sequence steps are 
always carried out one after the other and without any decision about 
order or exceptions. 


@ Decision Structures 


Decision structures are used when two or more actions can be taken, 
depending on the value of a specific condition. The condition should be 
assessed and then the decision is to be made and the set of actions for 
that decision should be carried out. Once the condition is determined 


the actions are unconditional. 


The decision structure uses the phrases IF-THEN-ELSE to point out 
alternatives in the decision process. Decision Structure can have many 
condition-action combinations . 


The following example shows the nesting of multiple levels of conditions 
and actions for each decision point. 


aE Tee eae, 
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If employee does not exist 
Else 
If grade < 20 
DA = 20% of basic 
HRA = 0 
Else 
If grade < 30 
DA = 20% basic limit to 600 
HRA = 400 
Else 
If grade < 40 
DA=0 
HRA = 40% of basic 
Else 
DA=0 
HRA = 50% of basic salary 
End if 


As can be seen above there are a number of conditions and action 
combinations. The example shows the nesting of multiple levels of 
conditions and actions for each decision point. IF-THEN-ELSE are the 
phrases used in the example. This clearly tells us the logic for the 
process of DA and HRA calculation. 

@ Iteration Structures 

It is common to find activities which 

e Have to be repeated ‘while’ a‘certain condition exists 

e OR repeated ‘unti? a particular condition occurs. 


Iteration instructions describe these cases. 


Sia... . “2. 
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Example: 


DO WHILE there are employees 
If employee does not exist 
Else 
If grade < 20 
-DA = 20% of basic 
HRA =0 
' Else 
If grade < 30 
DA = 20% basic limit to 600 
HRA = 400 
Else 
If grade < 40 
:DA=0 
HRA = 40% of basic 
Else 
DA=0 Se fin : 
HRA = 50% of basic salary 
End if 
End do ~ netebs = 


In the above example we have used DO WHILE. You can use DO UNTIL 
as well. In both cases the process will be repeated till the condition 
specified exists. 


4.4 Decision Trees’ 


Decision Trees are used when the condition and action combination is 
not very complex. Trees are also useful when it is essential to keep a 
string of decisions in a particular sequence. 


4.4.1 Decision Tree Characteristics 


A Decision’ tree is a diagram that presents conditions and actions 
sequentially (in: order) thus showing the order of conditions. This 
method shows the relationship of each condition and its permissible 
actions. The diagram resembles branches of trees, hence the name. 

Figure 4.2 shows a decision. tree where the sequence of decisions is 
fomi left a right. The root is on the left, this is the starting point of the’ 
decision sequence, the branching moves towards the right. The 
ssn aaa CT ET 
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particular branch to be followed depends on the conditions that exist 
and the decision to be made. 


Action 


= Action 


Condition 
Action 


A Condition 
Action 
Action 
Condition: : 
ee à ; Action 


Root 


Action 


Condition each ii 
Action 


Fig. 4.2 


Movement is from left to right, along a particular branch and is the 
result of making a series of decisions. Each node of the tree Tepresents.a 
condition. Before moving to the next path, a decision on which 
condition miste has to be made. The right side of the tree lists the 
artons Ka ybe, Slee. depending on the sequence of conditions that have 


4.4.2 Using Decision Trees 


One of the benefits of using a decision tree E that anal: z Ji 

- Z t fi 
formally identify the actual decisions that must be Saer Orente 
decision trees into an If-Else structure is very easy when 
conditions have to be checked for. many 


It is not easy for them to overlook an integral step i aa 
4 in the d 
process. Decision trees force analyst to consider ‘the Secuies? te 


conditions. 
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IDA = 20% of 


Root 


Figure 4.3 
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These points can be clearly seen in figure 4.3 which shows the process 
to arrive at the DA and HRA of an employee, based on the grade of the 
employee. Calculation should be done only for employees still existing is 
the company. The slab is as follows: 


Grade 10 - 19 DA = 20% of basic salary 
HRA = nil 
Grade 20 - 29 DA= 20 % of basic 
HRA = 400 


Grade 30-39 DA = nil 
HRA = 40% of basic _ 


Grade 40 & above DA = nil 
HRA = 50% of basic 


While drawing a decision tree keep the following steps in mind: | 


e Identify all conditions and actions and the order and timing of 
these. 


e _ Begin building the tree from left to right, while making sure you 
have completely listed all possible alternatives, before moving 
over to the right. 


Ans: 1) a) Structured English b) Decision Trees c) decision tables 
2) a) sequence structures b) decision structures c) Iteration structures 


3) one after the other 
4) right to Icft 
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4.5 Decision Tables 


Decision trees are not ‘always the best tool for decision analysis. A 
decision tree if used for a very complex ‘system with many sequence 
steps and combination of conditions will have a large number of 
branches with many paths through them, which will only cloud rather 


than. aid, analysis. Messe sacle Eee lena arise, Decision Tables should 
be considered 


mm 
t f 


A Decision Table is a table of rows and columns, that shows conditions 
and actions. ‘Decision Rules’, included a decision table, State what. 
procedure to follow when certain conditions exists. 


4.5.1 Decision Table Characteristics °°") ©" n> 7 s 


The Decision Tableti is medn up of four sectionis: 


° < Condition Statements: ari we malog aif) ay 
e Condition Entries ( Aoma 3 
o PNE i nog JIRAFA nì agauinaos 
° AchonEntiesg 0 


TO. 


, Conditions dnd Actioria: O OL = ms 


Condition Statements | 


: Entries(Alternatives) 


- Action Statements : 
: i wre ch 
sergilifsie? 10 SOLS? fe e - X 
Pes? wiat oc Fig'4a° itches aa a ean 
The condition. statement erans me relevant Conditions, | ke mae TEAR 


ri ab pbs Gi 
ther 


Condition Entries PE r e) tell which value; if any, » applies for a 
particular condition: a roivibres tart ort 


Action Statement list the s set of all JI stepe that canbe talen wen a certain 
condition occurs. ` a brie 20 iit te 


fri afir fi 
ii : -x 
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Action Entries show what specific actions in a set to take, when selected 
conditions or combinations of conditions are true. ‘ 


You can enter a note below the table to help state when to use the table 
or to distinguish it from other tables. The columns on the right linking 
conditions and actions form decision rules. o ; 


These state the conditions that must be satisfied for/a particular a set of 
action to be taken. For Decision Tables unlike decision trees there is rio 
order sequence. The decision rule incorporates ‘all’ the conditions that 
must be true, not just one condition at a time. © faldsT agiaiesti f 


igi i’ are 


4.5.2 Building Decision Tables 
To Develop Decision tables the following steps should be ‘used: 


1. Determine the most relevant factors to be considered: in making a 

decision. This identifies the conditions in the decision. Each condition 

selected should have the potential to either occur or not:occur:: Partial” 
occurrence is not possible. 

2. Determine the most feasible steps or activities under varying 

conditions ( not just the current conditions). This identifies'the actions. 


3. Study the combinations of conditions that are possible. For every N 
number of conditions, there are 2N combinations to be considered. For 
example, for three conditions, there are eight possible combinations; 23 


= 8. For four, 24 = 16. combinations are possible and:can be included in 
the table. $ re ; 


pn or OD zi G MOBS 
ae T in the table with decision rules. There are:twowàys to ‘fill in the 
e. - —_ - oe $ - e... - - i 


l. Ina longer method, here you have to fill in condition rows witha 
yes or no value for each possible combination of conditions 

2. The other method of completing the. table deals with one 
condition at a time and adds to the table for each additional: 
condition but does not add duplicate combinations of conditions 
and actions, asdiscussed.,,.. -— T SUGAR gorse 


post pe hey | 


a. State the first condition and permissible attends. 


‘b. Add the second condition by duplicating the firs ‘ha if x 
: SRNR t ERGI 
of the matrix and filling in the different Y and N values 
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from the new condition in both halves of the'expanded 
matrix. 


c. Repeat set b for each additional condition. 


5. Mark action: entries with X to signal action(s) to take; leave cells 
blank or mark with a dash to show that no action applies to that row. 


6. Examine the table for redundant rules or for contradictions within 
rules(discussed below). 


Following the above simple guidelines will help to: .~ 


@ save time in building a decision table from collected 
information. ; : 


a point out where information is missing 
@ show where conditions do not matter in a process 


a indicate where there are important relations or results that others 
were not aware of in other words not considered — 


Thus using decision tables can produce more complete and accurate 
analysis. 
4.5.3 Checking Decision Tables 


After constructing a table analysts verify it for correctness and 
completeness to ensure that the table includes all the conditions, along 
with the decision rules that relate them to actions. Analysts should also 

examine the table for redundancy and contradictions. $ 


ani 


Eliminating Redundancy satin ipi Diyos 
Decision ‘Tables are likely to get too large if allowed to grow in an: 
uncontrolled way. Removing redundant entries help to manage table 
size. Redundancy occurs when: 

1. Two decision rules are identical except for one condition row 

2. The actions for two rules are identical. 
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© Removing Contradictions 


Decision rules contradict each other when two or more rules have the 
same set of conditions and the actions are different. This could occur 
when either there is an error in constructing the table or when the 
analysts receive discrepant information from different individuals about 
how decisions are made. 


e Impossible Situations 


When building decision tables, it is possible to set up impossible 
situations. Now let us see an example for impossible situations. One 
thing we have to make sure is to see that accuracy is maintained and 
redundancy is avoided. In the table 1 below, Rule 1 is not possible as a 


person who is earning more than Rs. 50,000 per year cannot earn less 
than Rs. 2000 per month at the same time. 


__ ea 
Salary > Rs. 50,000 per year Y Y N N 
Salary <2000 per month Yy N Y N 
y 
Action 1 
Action 2 


Table 1 - Decision table checking 


for impossible situations 


Impossible situation 


Developing Decision Tables 


In order to build decision tables, the analyst needs to determi 

r , , t ermine the 
maximum size of table, i eliminate any impossible. _ situations, 
roine or redundancies, and simplify the table as much. as 
possible. ; 


1. Determine the number of conditions that may affect the decision 


Combine the rows that overlap. For example, conditions that are 


mutually exclusive. The number of conditions b 
of rows in the top half of the decision table. iSiunensasnumber 


ED -—S"Ss= St a a 
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2. Determine the number of possible actions that can be taken. This 
be: omes the number of rows in the lower half of the decision table. 


5. Determine the number of conditions alternatives for each 
condition(rules). 


4. Calculate the maximum number of columns in the decision table by 
multiplying the number of alternatives for each condition. 


5. Fill in the condition alternatives. Start with the first condition and 
divide the number of columns by the number of alternatives for that 
condition. For e.g., for 2 conditions, there are 8 rules. Divide 8 by 2. 
(23). So write Y in four columns and N in remaining 4 columns as 
follows: 


Condition 1: Y Y Y Y N N 

Condition2: Y Y N N.Y Y 

Condition 3: Y `N Y N Y N 

“ According to the decision tree oxen 
given below: 


Conditions and Actions __ 


‘Grade between 10-19 
Grade between 20-29 
Grade between 30-39 


=>- 


Note: It is assumed that all employees exist. 


6. Complete the table by inserting an X where rules suggest icer tain 
actions. 


>j 
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7. Combine rules where it is apparent that an alternative does not 
make a difference in the outcome. For e.g., 
Condition 1: Y Y 
Condition 2: Y N 


Action 1 X X 
This can be expressed as: 
Condition 1: Y 
Condition 1: - 
Action 1 X 


The dash (-) signifies that condition 2 can be either Y or N and the 
action will still be taken. ` 


8. Check the table for any impossible situations, contradictions, and 
any redundancies. According to the earlier .example there are 
certain impossible situations and redundancies. Take rule 1, 2, 3 
and 5. In all these rules, there are two Y’s, actually speaking a 
person cannot have two grades, he has to be in a particular grade, 
so these rules have to be eliminated as, it is an impossible 
situation. 

~ The last rule says that a employee exists but then there is no grade 
given to that employee, here there is a contradiction so again this 
has to be eliminated. 


9. Rearrange the conditions and actions (or even rules) if this makes 
the decision table more understandable. 


Note: The decision table for the example above has been explained in 
the limited entry table after eliminating all impossible 
situations. 

4.5.4 Type Of Table Entries 

There are four types of table forms: 

æ  Limited-Entry Form 

@ &xtended-Entry Form 

æ Mixed-Entry Form 


æ ELSE form 
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a Limited-Entry Form a 


The basic table structure consists only of Y’, N’, and blank ences This 
is a limited-entry form. It is the most commonly used formats. 


This decision table is made according to the example given in decision 
tree. We have arrived at this table after eliminating all the impossible 
situations, contradictions and redundancies: This has already been 
explained. A i 


Decision Table with Limited Entry form ~ ~ ~~ zei 


Employee exists’ 

Grade between 10-19 
Grade between 20-29 
Grade between 30-39 


Grade greater than 39 


DA 20 % of Basic, HRA= 600 -~i 
DA 20 % of Basic, HRA = 400 : 
DA =10, HRA = 40.% of Basic 
DA = 0, HRA = 50% of Basic 

No Calculation 


Table? 


a 


2 = s . sg: S d as fs ple 
In a limited entry decision table, the condition are expresse aS simple 
Yes or No quéstions, whereas ina Extended Entry table See 

{ ost ake TTO 


have môre than two possible states. < ` i en 


rieger 


o Extended-Entry Form rot 


The ete denen ty form replaces Y and N-with action entties telling the 
reader how to decide. Here the condition and action statements 
themselves ‘are not complete, therefore’ the entries contain more ten 
one Yes and No. BESS : 
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In the extended entry form, the condition is that, if an employee exists, 
and if he is in marketing department (“MKT”) he is eligible for 
commission. The commission is based on the total sales made for the 
month and is calculated as follows: 


If sales >=10000 then commission is 20% o 


if sales >=5000 and <10000 then commission is 10% 
if sales <5000, commission is 0 


The table is shown in table 3. ; : 


Employee exists Y Y Y Y N 
Department MKT MKT ADM MKT - 
Total sales 10.000 2000 - 5000 - 


Commission applicable 20% 0 


Table 3 


Note: n.a is Not Applicable 


The decision table above explains how the commission is given 
according to the sales per month. According to these conditions the 
actions have to be taken.: In the first rule, the person exists, he is in 
“MKT” department, and his total sales is upto 10000, so he is eligible for 
commission, he will get commission, 20% of sales amount: 


In rule 3, the person is in “ADM” department, so he does not have any 
sales figure, so he is not eligible for,any commission as such. 


æ- Mixed-Entry Form 

This form consists of combined features of limited and extended-entry 
forms. Generally only one form should be used in each section of the 
table, but between the condition and action sections, either form may be 
used. 

Now let us see an example of the mixed entry form, eere are 
various combination of conditions and actions taken. 


According to the company’s rules and olicies, followi 
conditions and actions to be taken P owing: are. the 


——————— P a 
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1) For all employee in the grade 10-19 and those in marketing 
department commision is calculated: as follows: 
If sales >=10000 then commission is 20% 
if sales >=5000 and <10000 then omission is 10% 
if sales <5000; commission is 0 : | 
If the person is in any other department then he 3 not entitled for 


commission. : 


2) Second condition is to check if the employee is supposed to pay 
income tax. This is done as follows: 
If the employee’s salary >= 50,000 - Tax applicable 
-< ‘Gf salary <50000 - Tax not applicable 


Tax is calculated for employees of all departments. 


Conditions and Actions 


Department 
Grade 10- 19 


MKT MKT FIN FIN MKT 
Y Y Y Y 


Salary >= 50,000 p.a. Y 
Salary < 50,000 p.a. 


Total sales 


Y Y 
10000 3000 


20000 


20% 10% n.a n.a 0 
X - X a > 
a X - X X 


Commission applicable 
Income Tax applicable 
Income Tax exempted 


Table 4 


The decision table in table 4 explains the following : 


is in * the grade is 
In the first rule, the person is in “MKT” department, 
between 10 and 19, and the salary per annum is more see 50,000 and 
sales is Rs. 20,000. The action taken for this rule is - 20 comune 
is given because he is in marketing department and he is applicable for 
Income tax. 3 
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In rule 4, the employee is in Finance (“FIN”)department, — grade is 
between 10 -19, and salary less than 50,000 per annum, so he is 
exempted from income tax, and he is not given any commission as he is 
not in marketing department. 


In rule 5, he is in marketing department, his grade is between 10-19, he 
need not pay income tax as salary Jess than 50,000; he is not given 
commission as his sales is only Rs. 3000. 


All these tables are made while design specifications are made. Each 
table is made according to a required module, and you can see how 
each table is designed and how actions are taken. 


a- ELSE form 


‘This form aims at omitting repetition by using ELSE rules. 
To build an ELSE form decision table 


> specify the rules with condition entries to cover all sets of 
actions except for one 


» This will be the rule to follow when none of the other explicit 
conditions are true. ` 


> This rule is the final column on the right, the ELSE column. 


> Ifnone of the other conditions are true, then the ELSE decision 
rule is followed. 


The ELSE rule eliminates the need to repeat conditions that lead to the 
same actions. 


The conditions for the ELSE form is that the empl i 
o E d ployees of marketing 
department are given commissions according to the total sales done: 


The commission is given as follows: 


If Sales >= 10000 then 20% commission 

if sales >=8000 and sales<10000 then 15% commission 
if sales >=5000 and sales <8000 then 10% commission 
else 

if sales <5000 then 2% commission 


Se ee SS 
SSAD . 
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7 Conditions and Actions 


Sales >= 10000 
Sales >=8000 and <10000 
Sales >=5000 and <8000 . 


Commission 
Table 5 .., 


The Else form decision table shown, below has an extra ELSE column. 
The ELSE is applicable for all marketing department employees who 
have made sales less than 5000. 

The first rule tells us that.the employee is in marketing department, his 
sales amount is. between -8000 and less than. 10000 so he gets 15% 
commission. i i f : ; ise 


Exercise -2 


Ans: 1) Condition statements, Condition entries, Action statement , Action entrics 
2) Limited-Entry Form Extended-Entry Form Mixed-Entry Form rer 
ELSE form 
3) "Y^, ‘N’, and blank entrics. 
4) This form aims at omitting repetition by using ELSE rules. 


Summary 


; i izati isi d processes i the 
Documenting org tion decisions an s requires 
identification of conditions and actions and learning ue What 
information is available to suggest actions to take when specific 
combinations of conditions arise. ; 
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The three documentation tools for decision making and procedures are: 
1. Structured English 

2. Decision Trees 

3. Decision Tables 


Structured English is used to state decision rules. The three types of 
statements are . 


> Sequence structures - shows unconditional actions. 
+ Decision structures - shows repetitive actions. 


+ Iteration structures - shows actions that occur only when and 
while certain conditions occur. 


Decision Trees are presentations of decision variables that are graphic 
and sequential, showing which conditions to consider first; which 
second, and so on. The root of a decision tree is the starting point for 
analyzing a specific situation, and the branches indicate the sequence 
of decisions leading upto the proper action to take. 


Decision Tables relates conditions and actions through decision rules. 
A decision rule states the condition that must be satisfied for a 
particular set of actions to be taken. The decision rule incorporates all 
the conditions that must be true at one time, not just one condition. 
There are four forms nf decision tables: 

+ Limited-entry 

+ Extended-entry 


+ Mixed-entry 
+ ELSE forms 


All forms should be developed without redundancy and contradiction . 
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Chapter 5- 


Structure Charts 


At the end of this session, you will be able to: ~ 

Know whatis Structured Design — : PE 
Understand what Structured Charts maar their purpose 
Define a Module tow | 2 
Draw Structured Charts 

Know the principles of Structured Design 

Know Structured Flowcharts 


Understand Transaction. Analysis 


Y y y y 2 


Understand Transform: Analysis 


5.0 Introduction i rPe eed 

Structured ‘Design which is one“of the phases' of System Development 
Life Cycle focuses on the development of software specifications. 
Structure Charts, show the relation of processing modules in computer 
software. This section discusses the development and use of structure 
charts. You will also be introduced to structured flowcharts, transaction 


analysis and transform analysis. : 


erw 
SEFT. G 
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i 
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5.1 What Is Structured Design ? ¢ 


Yalow. À 
itation of proce logic, we 

i the documentation of procedure and system > 
= ‘ay that ee REE stage has been completed. ‘Structured Design 
uses Logical DFDs, Data dictionaries, normalized oeme e 
process specifications which “have been developed during analysis 


phase. 

os tt graphic descriptions. It 
Structured Design, is another element that uses graphic dest 
ioe dsea SA scitare specifications. Well Structured designs improve the 
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maintainability of a system. A structured system has the following 
qualities: 


> Itis developed from top-down 
> Itis modular, that is broken down into manageable components. 


> The modules should be designed so that they have minimal effect 
on other modules of the system. 


Vv 


Connections between modules are limited and interaction of data 
is minimal. 


> This helps easing maintenance tasks. 


y: 


The major tool used in Structured Design to depict the structure ofa 
system is the structure chart. 


5.2 Structure Charts 


The fundamental tool of Structured Design i is the structure chart. Itisa 
widely used tool for designing a modular, top-down system. The logical 
DFD forms the basis for drawing structure charts. Like Data Flow 
Diagrams, Structure Charts are graphic descriptions, they describe 
interaction between modules and the data passing between modules 
that interact with one another. These functional module specifications 
can in turn be passed to programmers prior to writing program. code. 


Pa 


CETEMBLOYEE ; Me ae Calling Moduler yswil 
1i DETAILS" : ; 
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In the figure 5.1, ‘GET EMPLOYEE DETAILS’ calls FIND EMPLOYEE 
NAME’. There is data passing between the two modules. 


e GET EMPOLYEE DETAILS sends data emp. no. to FIND EMPLOYEE 
NAME. 


e FIND EMPLOYEE NAME (having done its function) returns data 
Emp. Name to GET EMPLOYEE DETAILS, and 


e FIND EMPLOYEE NAME also returns a flag (Emp. No. Is OK) to GET 
EMPLOYEE DETAILS . This is used to tell the calling module (caller) 
that everything went well because sometimes GET EMPLOYEE 
DETAILS may send a flag saying ‘invalid emp. No.’. : 


5.3 Purpose Of Structure Charts 


A Structure Chart is a design tool that visually displays the relationships 
between program modules. It shows which modules within a system 
interact and also graphically depicts the data that are communicated 

between various modules as seen in Figure 5.1. 


Structure Charts are developed prior to the writing of program code. 
They are not intended to express procedural logic (this is done by 
flowcharts and pseudocode ), nor do they describe the actual physical 
interface between processing functions. 


Structure Charts identify the data passes existing between individual 


modules that interact with one another. The communication between 
modules of a Structure Chart can be clearly seen in Figure 5.1. 


J ri 
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5.4 Notation 


A common notation is used in the development of structure charts for 
uniformity and ease of communication among systems developers. 


Calling 
Module a 
Called 
Module 
Module Symbol Arrow call 
Symbol 
Sender ‘Receiver Sender Receiver 
e¢——> 
‘Data couple’ or Control Flag 
parameter symbol Symbol 
LO 
Decision Loop- repetition 
Symbol .. Symbol ° 


Figure 5.2 shows Primary Symbols Usea in Structure charts. 


1. Rectangles : Represent modules. Module name is written inside the 


rectangle. 


2. Arrows : Indicates that one module calls another; di i 

WS | ° ; dir 
arrows indicates which module is calling. Arrow also apis onshore 
information between modules. In traditional programming lan; es. 
call are made by the execution of PERFORM and DO statements. ore 


3. Small arrows with empty circles: Is used to note th i 
s : j e pass ta 
parameters - ‘data couples’. These are items of data nected in the called 
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module to perform the necessary work. They indicate that something is 
passed down to the lower module or back upto the upper one. 


4. Small arrows with filled in circles: These represent control flags. Its 
purpose is to assist in the control of processing by indicating the 
occurrence of, say; end-of-file conditions or errors such as a transaction 
was not valid, or no such employee exists. : 


The fewer data couples and control flags one has in the system the 
easier it is to change the system. When these modules are actually 
programmed, it is important to pass least number of data couples or 
parameters between modules. 


5. Loop : Indicates that the procedures found below this loop are to be 
repeated until finished. s 


Figure 5.2 (a) shows that the process ‘CALCULATE EARNINGS AND 
DEDUCTIONS’ found below the loop will be repeated until the net pay 
for all employees is completed. š 


CALCULATE 


DEDUCTIONS 


Figure 5.2(a) 


i : This appears on the bottom of a rectangle. This 
sere rae aoe sae Ane modules below the cimene will be 
performed. In figure 5.3 the small diamond is found on he. pitom af 
rectangle marked ‘Maintain Master Employee Pay Details’ . 1 
indicates that either the module Write New Employee Details ses 
‘Update Employee Details’ will be performed. This symbol represents the 


selection construct. 
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5.5 Definition Of A Module 


In Structured Design, a ‘module’ is defined as a set of instructions 
which can be invoked by name. It:is a group of instructions, i.e., a 
paragraph, block, subprogram, subroutine or the like. 


Contents of a module can be referred to collectively under a single label. 
The label should tell us just what the module does nothing more and 


nothing less. 

Module names are important part of the notation. The rule is that the 
name of a module summarizes what the module does. The module name 
consist of an Action verb and object noun e.g. In the module called 
“CALCULATE NET PAY”, CALCULATE is the action verb and NET PAY is 
the object noun. The name itself tells us that this module calculates the 


net pay but, it does not tell us how it does it. A module ideally serves 
only one function. 


5.6 Drawing A Structure Chart 


Structure Charts are to be drawn top-down. The first level logical DFD 


(figure 2.5) should be used to find the processes that are to become the 
modules in the structure chart. 


Our first level logical Data flow diagram consists of four processes: 
e 1. Maintain Master Employee Pay Details 

e 2. Maintain Employee Transaction Details 

e 3.Calculate Net Pay 

e 4. Print Reports 


These form modules in the structure chart. 
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STRUCTURE CHART 


PERFORM 
PAYROLL 


End of Emp. 
details 


Employee Pay 
Details 


New emp 


aa, 


Employee 
Details 


mr New 
details of 
N Pr. cmp 


Employee 
Details 


Calculate 
Eamings & 
Deductions 


Fig. 5.3 Structure Chart 


i i .3. The main process at the top 
The Structure chart is shown in figure 5-3. 
of tas is called “PERFORM PORO mga See me bene 
erything eath. mo 
hear ete aes e A of the processes in the data flow 


. diagram.. 


o a i en 
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Since the data flow diagram is intended to be a logical representation of 
the system, it is not unusual that the modules would be the same. The 
modules on the second level will control the operations of the modules 
on the third level. 


These modules accomplish separate functions such as “WRITE NEW 
EMPLOYEE DETAILS? , “CALCULATE EARNINGS AND DEDUCTIONS” 
and so on. 


In this example, the data couples and control flags are kept to a 
minimum. The hierarchical structure makes the structure chart appear 
to be an inverted tree. 


Later in the session we shall see how the DFD can be converted into a 
structure chart using transform analysis. 


Exercise - 1 


Ans: 1) Structure chart 
2) before 
3) rectangle 
4) small arrows with filled in circles 
5) data couples 
6) 


SSAD 108 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


5.7 Principles Of Structured Design 


As already studied structure charts is the major tool used for structured 


design. Besides this there are other aspects that one should know of 
structured design. 


In this section we will describe in brief each of the following points 
which are useful for structured design. 


e Top-Down Structure Of Modules 


e Coupling 


e Cohesion 
ə Span Of Control 


o. Size 
o. Shared Use . 


5.7.1 Top-Down Structure Of Modules 


Top-Down methods are used throughout the analysis and design 
ea This approach, starts with the understanding at a very a 
(top) layer of the system which is then ‘exploded’ (as apas i Ma 
chapter 2 under data flow diagrams) to lower levels where greater de 
of the system is understood. The top general process wa havatan 
levels (sub systems) of modules below it: These modu. sipa RE 
specific tasks. This approach can be clearly seen when we studie 

flow diagrams and structure charts. 


5.7.2 Coupling 


‘Coupling’ refers to the ‘strength’ of the relationship be mpane in 


a- system. The strength of a relationship i.e., coupling is determined by 


the data passes between modules and on the dependence of one module 


on another for input. For a good system. dealen EST ne ed 
module with another should be minimum. n gla Soo 
coupled. When modules are loosely coupled, changes tc de 


will not have a cascading effect - i 
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As mentioned above loose couplings minimizes the interdependence 
between modules. This can be achieved in the following ways :- 


> Control the number of parameters passed between modules. 
> Avoid passing unnecessary data to called modules. 
> Pass data (upward or downward) only when needed. 


> Maintain superior/subordinate relationship between calling 
and called modules. 


> Pass data, not control information. 


If you see figure 5.1 notice that employee number is sent by ‘GET 
EMPLOYEE DETAILS’ to FIND EMPLOYEE NUMBER’. 


This employee number being the record key, distinguishes the employee 
record and helps to get all the required employee details. As it is the 
record key, it is unlikely to change, other items in the record may 
change. Hence, the loosely coupled alternative is better suited to 
achieving the stated design and maintenance objectives. 


Passing too little data can make it impossible to perform the 
task(function). In case the employee number is not passed to the sub- 
ordinate module then it is not possible for the sub-ordinate module to 
know which record to locate. 


‘Floating data’ should be avoided in designs. This occurs when one 
module produces data that are not required by the calling module but 
by another, elsewhere in the system. These details pass through the 
system till they reach the function that requires them. 


5.7.3 Cohesion 
As seen in the previous section an important way to evaluate the 


partitioning of a system is by how cleanly the modul 
from one another - that is the criterion of coupling. . = a ame 


Another way to determine partitioning is to look at Haan the: activiti 

. e activities 
m thin’ a single module are related to one another. This is the criterion 
of ‘cohesion’. 
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A module should be highly :‘cohesive’; that is,- each module should 
accomplish one and only one function. In properly modularized, 
cohesive systems, the contents of the module are so designed that they 
perform a specific function and, are more easily understood by people 
than systems designed by other methods. Hence cohesive modules are 
not largely dependent on other modules. 


Contents of the modules determine how cohesive the module is. These 
contents can be categorized in the following manner : 


1. Module contents not closely related : 


Modules in this case are developed by size or number of instructions 
i.e., when programmer works according to strict rules and divides 
modules into sections of'50 statements each; all modules must fit on a 
single page. 2 JA 


2. Module contents determined by logic of processing: 


All steps are performed together or handle the same functions. Here the 
elements are related by ‘time’ at which they are performed; i.e. they 
logically seem to go together and are performed at the same time. For 
instance a module that initializes all variables and opens files is 
logically bound. re 
In this case all the elements are executable at one time. Modules that 
_ are logically bound are difficult to modify. Even the simplest change ea 
* effect all types of transactions. It“is better to separate each type o 
transaction into its own module: “me cart ; 


3. Module Determined By Data Used: 


ts i odule refer tothe same data or files. A 
E the EREE ion and updates the master file by 
adding, deleting or changing) records, including ge aE arat 
for each type of function, shares a common set Gs HAGE Cl 
binding is so far'the best. e.g: Printing, displaying an | copying, iat 
a common file. | 


~~ risen E a a a P d; 
4. Module Contents Determined by Function Performe 


All aci:vities in a module have the same single pirpope thal 1a peor, 
a single function: This provides more thorough totog ee ogule tt 
changes are needed at a later time,;one can easily determin 


wi 
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we. 


module is constructed and how it processes data aid interacts with 
other modules in the system. 


The emphasis on reliability and maintainability is constant throughout 
systems development. 


Coupling : Strength of 
relation between 
z modules 


Coupling ` 


_ Cohesion: Strength of 
_ Telations within modules 


MISEL 


Figure 5.4 depicts coupling.and cohesion in software des ign. 


Thus -a good design should fee an ideals ‘combinati F 3 
cohesive and loosely coupled modules. om vas oe highly 


"eis 
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5.7.4 Span Of Control 


Span of control refers to'the number of sub-ordinate modules controlled 
by a calling module.: In general the number of sub-ordinate modules 
should be limited to, five to seven. Modules should interact with each 


other and manage the functions of a limited number of lower-level 
modules. 


When the number of sub-ordinate modules are very high, then it gets 
difficult: in determining which -module to invoke under certain 
conditions. It is also difficult in establishing calling sequences to pass 
data and receive results. 


This results from not applying objectives of coupling and cohesion. 
5.7.5 Module Size 


The number of instructions contained in a module should be limited so 
that module size is generally small. i : 


Some of the guidelines ‘(these should not: be strictly used as’ thumb 
rules) to manage module size are : 


e Module should contain not more than 50 instructions. 


°. ‘Listing of source code for a module should fit on a single 
printed page. DMS 


In general modules should focus on a single purpose, be highly cohesive 

and loosely coupled. Yet the modules should ae be ee apne e sre 
n the language. For example: c 

rpe ron pate 5 calculations will be more than ‘C’ code 


to perform a series of ari 
OR COBOL code to generate a report will be more than FoxPro code. 


5.7.6 Shared Modules 


Functions such as calculations or a particular typa oes 
not be duplicated in separate modules. They shou Ltr REREN, 
single module that’ can be invoked’ by any other viet be designed and 
This minimizes the amour oc ea that must be made 
written. It also minimizes the n AEN : a OT caléulation 
during systems mtn e if 
procedures change, only one E ules). 
shared module principle (also known as library module ) 
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Many systems establish library modules - which are 3 predefined 
procedures that are included in the system’s program library. -The 
routine is quickly invoked by a single command or call. 


5.8 Structured Flowcharts 


Structured flowcharts, also called Nassi-Schneiderman charts (or N-S 
charts), are graphic tools that force the designer to structure software 
that is both modular and top-down. The advantages of the Nassi- 
Schneiderman chart are : 


> it adopts the philosophy of structured programming 


> it uses a limited no. of symbols so that the flowchart takes up less 
space. 


They provide a structure that can be retained by programmers who 
develop the application software. The responsibility of leveloping 
module logic, varies from organization to organization. The 
responsibility could be the analysts or the programmer's. 


5.8.1 Basic Elements 


There are three basic elements used in developing structured 


flowcharts. F:zure 5.5 shows the three basic symbol draw 
Nassi- Schneiderman charts. cae ee 


Process Decision Iteration 


Fig. 5.5 


There are many similarities between th 
components used in structured English. ese elements and the 
Process: Simple processes or steps in a pro, 

gram are r ted by a 
rectangular box, the process symbol. This ae by a 
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initialization of values, input and output activities, and calls to execute 
other procedures: 


A name or brief description written in the box states the purpose of the 
process. The succession of steps is shown using several process boxes. 


Decision : The decision symbol represents alternative conditions that 
can occur and that the program must have a manner of handling. Any 
form of a decision including several condition alternatives can be 
depicted using this symbol. They show the equivalent of the IF-THEN- 
ELSE structures discussed in structured English and common in many 
programming languages. 


Iteration : The iteration symbol represents looping and repetition of 
operations while a certain condition exists or until a condition exists. 


ees Option 


i ‘\. Do While option is aoe exit? from Master maintenance menu 


ecervenvesesercoeseverncces: sweceuensetsepnsesverseneessastnuneracsusserserent® 


Base Write New Emp. Details / 
i + Update Old Emp. Details 


i rite new emps ~~~ i _— Upd. Old Emp. 
i Details si a Details © 


Accept new emp. No. _ 
Jalidate no. 
Accept all details 


date aep code, gra grade code aCe De EP PANA 


| “Any errors ?__. 


i j Yes No. 

| Display error i write new 

: message. i Master record 
Is f z tnext 

i ccept correc- ; Accep 

i ion i option 

i eck errors 

Close Master File 


permet i 
eee module ‘Maintain Master Employee Pay 
Detai ils’ : 
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The benefits of Nassi-Schneiderman charts are : 


> They provide analysts with a tool for aiding the program design and 
development process because they are compatible with structured 


programming. oe 
> This chart is easy to read because no knowledge of complex symbols 
is required. À 

> It does not take up precious space either. 


> In summary, the Nassi-Schneiderman chart is a very valuable tool for 
the analyst. 


5.9 Transaction And Transform Analysis 


So far in the system development process we have developed an 
essential model of the system( logical DFD). The next stage of developing 
the procedural side of the system is to create the structure chart(s) for 
the system, from which we can ultimately develop the code. 


Having gone through those earlier stages of the SDLC, we will find it 
relatively Straightforward to achieve a structured design for the system. 
This section will present a pair of techniques called transaction and 
transform analysis which are used for deriving a structure chart. 


5.9.1 Transaction Analysis 


hia ‘ste ae git pli e umber of situations found in 
essing applications wo ; 
transactions. p ens would be considered as 


For example transaction types in our minicase should be “ da 

2 ah e “Ad New 
Employee”; Enter Emp ees exit code”; “Update Employee’s Say 
To identify the transaction type one adds a transaction tag such as :- 


=- N? for “Add a New Employee” 


So 


e 
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- ©’ for “Enter Employee’s exit code” 
- U’ for SU ae Employes: s record”. 


The system esda: some way to distinguish the transaction gpa and 
the human (operator/user) needs some brief way to tell the system 
which type of transaction stimulus he is placing on the interface. This is 


done by the human user by: selecting the ‘code’ for transaction Doe from. 
a menu of transaction codes. 


Figure 5.6.shows one transaction type of a;payroll RT that eS. 
payslips for employees using variable data.. - vi 


Having identified ‘the transaction Unes we need to design « each- 
one separately, by the techniques of transform analysis. T l 


5.9. 2 ET Anniysis 


Transform analysis, or -transform= centered digan is- the act for“ 
converting each piece of the data flow diagram that we isolate by 
transaction anayaia into a CES chart. 


Transform analysis is'a ‘strategy’ not’an ebrii heñte': it does not’ 
have fixed rules to follow. Therefore, transform analysis cannot oe 
carried out blindly by following , Steps, one has to “kocp in mind gaa Qo 


SIAT 


system is bee ac to perigee 


ho ek seas: 


Transform anaya is Compad of the following five steps: ` 
1. ‘Drawing a ‘data. fe dogam 
2. Finding the'central function ‘of the data flow disgrani z 
3. First level factoring 


4. Factoring of Afferent, Efferent, and Transform branches 


5. Departures 
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1. Drawing a data flow diagram 


In order to carry out the strategy of transform analysis, it is necessary to 
have a data flow diagram of the system’s analysis. This as mentioned 
previously helps one to study the flow of data through a system. 


2. Finding The Central Function Of The Data Flow 
Diagram 


Some modules receive information from sub-ordinates, and tnen 
pass it upward to their super-ordinate. This is referred to as an 
afferent flow of data, and the modules which behave just opposite to 
afferent modules are efferent modules. These efferent modules take 
information from their super-ordinates and pass it down to their 
sub-ordinates. 


Central functions of a data flow diagram are those functions in 
the middle of afferent and efferent data elements. 1a z 


Thus Afferent modules are those which are closest to the process. 
which will transform them into the processes output, they-are involved 
in the.processing of the input. ot okut- boxi i 


While Efferent modules are those that maybe Eea “logical , 
output data” , those involved in the processing of the output. 


Central functions is usually left in the middle after the afferent and’ 
efferent functions are identified. Central functions are the main work of 
the system. They transform the major inputs into major-outputs. 


Sometimes the afferent and efferent data elements-are ‘the same, in 
such cases there are no central functions. È 
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Central Function 


Validated 
dia 
P 
v PAYSLIPS 
Formatted 
ve cy) any 


PRINT 
PAYSLIPS 


Figure 5.6 


Figure 5.6 clearly shows that: 
ETAILS’ receives information i.e. ‘variables 
‘VALIDATE VARIABLE D ae Pernt ad 


details’ from its sub-ordinate ‘GET \ RE : : 
information i.e. ‘validated variable details upwards to its super-ordinate 


module called ‘CALCULATE NET PAY’. i 
which covers the modules VALIDATE 


Thus the region marked ‘A’ VARIABLE DETAILS’ denotes the 


VARIABLE DETAILS’ and ‘GET 
afferent stream. 

In contrast, the module ‘CREATE PAYSUES pakea; dafepmatiany Le 
‘Payslip details’ from its super-' rdinate an panes) 3 formated 
payslip details’ to its sub-ordinate ‘PRINT PAY . These | 
in the processing of the output 1€- payslips. 
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Thus the region marked B’ which covers the modules ‘CREATE 
PAYSLIPS’ and ‘PRINT PAYSLIPS’ denotes the efferent stream. 


‘CALCULATE NET PAY’ is found in the middle of the afferent and 
efferent stream. Hence this is the central function. It performs the 
main function of the system. It is involved with the transform of major 
inputs into outputs. 


3. First Level Factoring 


In this step of transform analysis the basic aim would be to convert the 
data flow diagram into a first cut structure chart by way of first level 
factoring. 


The process names will correspond with those found in the lugicai 
DFD. 


Having identified the afferent and efferent data elements of the system, 
we specify a main module which, when activated, will perform the entire 
task of the system calling upon subordinates. In our example the main 
module will be ‘CALCULATE NET PAY’. 


For each afferent data element feeding a central transform (main 
module), an afferent module (VALIDATE VARIABLE DETAILS as seen in 
figure 5.6) is specified as an immediate subordinate to the main module. 
Its ultimate function will be main module. 


Similarly, for each efferent data element emergin 

i g from any central 
transform, we define a subordinate efferent module ( CREATE PAYSLIPS 
and PRINT PAYSLIPS as seen in figure 5.6) that will accept the efferent 
data element and, ultimately, transform it into the final physical output. 


Finally for each central transform or functionall i posit 

ly cohesive composition 
of central transform module, which will accept from the nadie 
the appropriate input data and transform it into the appropriate output 


data; of course, this output is delivered Ñ i 
gaa ere pack upward to the main 


Thus, we can see that there is a simple correspond 
flow diagram and the initial first level structure chart. a ra data 


The main module is the overall control, or executive fi ; 
function is to control and coordinate the afferent f bea ng 
efferent modules dealing with the highest-level data of the eater It , 


=F eee 
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will call the immediately subordinate afferent modules to obtain major 
inputs, pass these to the appropriate transform modules, deliver the 
final results to the efferent modules. These calls will in general case, be 


imbedded in the major decision and iteration control logic for the overall 
process. : 


Hence at this stage we shall have three types of modules which will be 
subordinate to the main module. These three types of modules will be 
the efferent, afferent and transform modules. Having derived one level of 


the structure chart one now proceeds to factor: these three types of 
modules. 


4. Factoring of Afferent, Efferent, and Transform Branches 


Three distinct sub strategies are used to factor the three types of 
subordinate modules (afferent, efferent, and transform) into lower level 
subordinates. 


To see how an afferent module can be factored, look at the top-level 
afferent module and identify the transform (or computations) required 
to perform the function of this module. 


This identified transform becomes the function of a new transform 
module immediately subordinate to this afferent module. 


Each of these new lower-level afferent modules is factored successively, 
in the same manner until the ultimate physical input is reached or the 
process is otherwise terminated. 


i efferent modules is essentially symmetrical to that of 
e For a given afferent module, we are looking for the 
next transform to be applied which will bring the data closer to a 
ultimate “physical” form. The transform module that seep hence jis 
transformation will be subordinate to the “top-level” efferent module in 


the system. 


inserted as intermediate modules in 
and the functions from which they are composed. 


—— a UU 
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After factoring of efferent, afferent and central branches is done one 
arrives with a structure chart as shown in fig 5.7. 


Calculate Net 


Calculate 
Deduction 


Get 
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Produce 
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Empl Emp. Pay 
eee Details details 
Pay 2 ‘Formatted 
details Pay 
details 


Get K Format Print 
Attendance Attendance Employce Pay Payslips 
Details c Details Details : 


Fig. 5.7 
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5. Final step: Departures 


This strategy described so far assumes an orthodox structure in which 
the data ‘will flow inward or outward in any branch, but not both. 
Consequently, we expect that afferent modules will have only afferent 
and transform subordinates; similarly, efferent modules are expected to 
have only efferent and transform subordinates; and transform modules 


regardless of where they are in the structure should have only 
transform subordinates. na 


However, real world problems frequently require exceptions to these 
rules if clumsy processing‘is to-be avoided. For example, we could 
require afferent subordinates to a transform module or we could require 
afferent subordinates to an efferent module. ' 


We must always keepin mind that our objective is to make. the program 
structure reflect the structure of the problem as closely as possible. The 
detailed data flow diagram is a guide to the problem structure, and if 
the problem requirements necessitate a departure from orthodox 


transform centered organization, it should be apparent in the diagram. 


When completed, the trial structural design using transform analysis 
will bear a simple, straightforward relationship to the data flow. The 
final structure which will reflect many design trade-offs and heuristics, 
will be derived from systematic refinements and alterations of initial 
first-cut structure. These modifications may be made in a separate 
phase after completing the initial factoring, or as many designers prefer 
during the initial factoring. 


Exercise - 2 


Ans: 1) ling” 
2).Cohesion - 2 
3) Module should contain 
on a single printed page. 
4) Transaction analysis E Jesigi 


5) Transform analysis ontan Ti Structure Charts 


of source code ofa module should fit 


not more than 50 instructions and listing 
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Summary 
> Structure charts are an important tool for the software designer. 


They visually display the relation between program modules and 
graphically show the data communicated between each module. 


In general, two types of data are transmitted. 


l. Parameter data consist of those items needed by the module to 
do the necessary processing. 


2. Control information assists in the control of processing by 
indicating the occurrence of errors or conditions that affect process, 
such as the end-of-file. aay) 
> Six principles characterize good software designs: 
1. Top-down partitioning E 
2. Loose coupling 
3. Functional grouping for cohesion 
4. Iimited span of control : : ‘iy 
5. Managed module size 


6. Shared modules. 


Following these principles increases the likeli | ieving 
acceptable levels of reliability and S SE Ee Soa See 
> Structures flowcharts, also called Nassi-Schneid oes 
A p =- eiderman di S, 
define modules in a system using the three basic process, decision 


and iteration structures. Each is assembled i : 
to specify the logic of a module or system. in a top-down fashion 


> ‘Transaction analysis is the technique of i meee een 
types of a system using AT identifying transaction , 


» Transform analysis, or transform-centered design, is the strategy 
diagram into a structure 
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» There are five steps involved in transform analysis : 
1. Drawing a data flow diagram 


2. Finding the central function of the data flow diagram 
3. First level factoring 


4. Factoring of Afferent, Efferent, and Transform branches 


5. Departures 


— 5 Structure Charts 
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True men of action in our time, 
those who transform the world, 
are nof politicians & 
Statesman, but are scientists. 


- W.).Auden. 
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Chapter 6 . 
Input / Output Design 


At the end of this session, you will be able to: 
Understand the objectives of input design ' 
Know data capture guidelines ™ | 
Design a source docurnent 
Design a screen for input r: A p EE EES 
Understand the objectives of output design 3 


Know how to present information 


Design printed output at 


Y¥UvUUNvveuey 


Design screen output 


£ 


6.0 Introduction 


Design of inputs and outputs are important features of design 
specifications, The. input design is the link that. ties.the infcrmation 
system into -the world of its users. Output, as you. probablyknow, 
generally refers to the results that are generated by the system. For 
many end-users, Output is the main reason for developing the system 
and the basis on which they will evaluate the usefulness of ,the 
application. 


p 
E 


In this session we will discuss objectives of input design and output 
design, Data capture guidelines,. Presentation, formats and methods for - 
developing Source document, printed outputs and screen outputs...;__»- 


G 
s 


7: 
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6.1 Input Design 


The design decisions for handling input specify how data are accepted 
for computer processing. Analysts decide whether the data are entered 
directly, or by using source documents, such as variable forms where 
the data are transferred into the computer for processing. 


6.1.1 Objectives Of Input Design 


The Quality of system input determines the quality of systems output. 
Input specifications describe the manner in which data enter the system 
for processing. Input design features can ensure the reliability of the 
system and produce results from accurate data, or they can result in the 
production or erroneous information. The input design also determines 
whether the user can interact efficiently with the eta 


Six objectives guiding the design of the input Reus on: 
e Effectiveness s es | 

e Accuracy 

e Ease to use 

e Consistency abi 
e Simplicity 


e sEEcUveTesa) 
All these objectives are im ortant and 
na inciples. aa ip. : ‘can be” attained by the use of 


ISSIGE reet, me aisy . : 


sije 


Effectiveness: This means that input forms 


purposes. and screens. Serve specific 


FE aTe 


accuraci: refers to design that assures proper completion.. 


require no extra time to’ understand. This is dec 
automating manual systems. 


Consistency: means that forms and screen 
similar nature together. S should group data of 
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Simplicity : refers ‘to keeping the forms and screen ‘simple and 
uncluttered. 


Attractiveness: input forms ‘shotild be’ of appealing: design. “witch 
should please the user. i Earn Ba , 


6.1.2 Data Capture Guidelines 


There are general guidelines that will assist the analyst, in formulating., 
an input design. The analyst should start by capturing only those items 
that must actually be input. 


1.Variable data es x 
Those data items that change for each transaction handled or decision 
made. 


For example: The O.T hours of each employee varies, therefore it should 
be entered. On the other hand, the rate of O.T does not vary from 
employee to employee, so it need not be entered. The rate can be stored 
in the system and retrieved automatically when the O.T has to be 
calculated. 


2. Identification data 


The element of the data that uniquely identifies the record being 
processed. The identifying item in each transaction record is called a 


key. 


For example, during entry of the variables, the employee must be 
identified, by the employee number. The employee name or even some 
other data element could be used instead, but it might not be unique 
and could thus cause error, or it may be difficult to enter. 


Besides knowing what to enter, knowing what shouldnot be ent 
equally ‘poration procedures should not provide for the entry of the 
following data: nich = 


1. Constant data: 


This implies to data that are the same for ae T same e 
number of working days for the monis v oa The analyst 
employees, it need not be input for eye. i; E so that it directs 
should instruct the programmer to write the so 
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the user to enter the no. of working days.of the month before the 
process. 


In cases where the date is required the clock/calendar in the computer 
can be used or the current date can be accepted at the start of the 


entry. 
2. Details that the system can retrieve: 


This refers to the stored data that are quickly retrievable from the 
system files. - 


For example, when entering the employees variable data, there is no 
need for the entry of employee’s name , once the number is entered the 
name can easily and quickly be retrieved. ` 


3. Details that the system can calculate: 


This refers to the results that can be produced by.having the system use 
combinations of stored and entered data. 


For example, to compute the O.T payable of an employee, the O.T hours 
of the employee has to be entered, the no. of working days can be 
accepted at the start, and the basic salary details can be retrieved from 
the employee master file, using the employee no., naving this the O.T 
can be computed by applying the formula. 


6.1.3 Design Of Source Document 


This is also known as the input form. The source d í 
on which data are initially captured, i.e. recorded. e ee tes 


For example, the variable data input form sh i i 
source document for recording variable data e e 


By, definition, they are pre-printed or duplic i 
people to fill in responses in a standard SE e re athe Sees 


SS C0 
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HEADING ZONE 
ABC CO LTD. - [Name of the company, 
address etc.] 

Variable details for - 


CONTROL ZONE 
Date : 


For the month of : 
IDENTIFICATION ZONE 
DEPARTMENT : 


Variable details of Employee of ____ 


- DETAIL ae 


Emp. No. Days Absent O.T. Hrs. Adv. Sal. Misc: 
caei 7 2 Ea ing 


MESSAGE ZONE 
Special notes : 
Signature 


Total.Days absent , O.T‘ Hrs, 
Adv Salary etc: 


Fig. 6.1 


Zones to guide layout of source document 


In order to design useful; peie the following fou guidelines for form . 
design should be followed. ira 


1. Make forms easy to fill out. : 
2. Ensure that forms meet the purpose for which apace designed. 
3. Design forms to assure accurate completion. 


4. Keep forms attractive. 


There are a number of means to Shiva each tin fr form design: 
Each of the four guidelines is considered separately 
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1. Make Forms Easy To Fill Out 


In order to reduce error and for better speed for, entry of data, it is 
necessary that forms are easy to fill out. The cost of the forms is 
minimal compared to the cost of the time employees spend filling them 
out and inputting data to the computer. : 

There are three techniques to consider for design of Easy To Fill Out 


forms. 


> Designing a form with proper ‘flow’ is the first technique we will 
describe which helps making the form easier to fill. Forms should 
flow from left to right and from top to bottom, as people are used to 
filling or reading documents in this manner. It should be possible 
for the user to provide information by following a logical sequence 
rather than having to skip to different locations on the document. 


> The second technique that makes it easy for people to fill out 
forms correctly is ‘logical grouping’ of information. Seven main 
zones should be normally present for a good form layout. Figure 6.1 
shows zones guide layout of source document. 


> The third technique for easy to fill forms is using ‘Captions’ on 
the source document. Captions tell the user what data to provide 
and where they should be entered. Captions should be brief but 
easily understood, with standard terms that all persons using the 
form should know. Abbreviations should generally be avoided. 


Inclusion of simple examples will help eliminate unnecessary questions 
about what information to provide. a 


For example, in asking for date of birth, the form might 5 ecify how the 
date should be provided such as’ “MONTH, DATE, Ue or 

MM/DD/YY” or “MM/DD/19YY’ . This will help the person concerned 
fill the date in the required format. 


A well designed source document is easily com; léted! 
: and all 
process of actually recording the data to be rapid. p ows the 


2. Meeting The Intended Purpose 


Forms are intended to serve one or more po: i i 

; c Be ae purposes in recording, 
Processing, storing and retrieving of information for the buaii 
Sometimes it is required to provide different information to different 
departments or users while sharing some basic. information. This is. 
where special forms are useful. These Special forms consist of the 
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common basic information required by all, and the forms that are to be 
filled by the user/department which has to provide the added 
information, will have the added details. These add on details need not 
be present on the common form. 


3. Assuring Accurate Completion 


Error rates which normally arise during the collecting of data, will drop 
sharply when forms are designed to assure accurate completion. Design 
plays an important role in making people do the right thing. 


Yi p: 
The form design should provide for column totals and row totals and a 
provision to double check these totals should be available, so as during 
‘the‘data entry stage itself a keying in error or the error in the form can 
be detected and corrected then and there. Therefore an error is 
prevented, and the input for the processing will be more accurate. 


5 i 
Sa 


4. Keeping Forms Attractive 


Although dealt with last, an attractive appearance of the form helps in 
better and faster completion. Basically the forms should not, look 
cluttered. They should appear organised and logical even after. they. are 
filled in. Providing enough space for typewritten or hand-written 
responses will help in this regard. Proper layout and flow. contribute to a 
form’s attractiveness. 

; ; ris} x WU 


6.1.4 Design Of Screen Design Cag 

The completed source document or form is used to enter the data for the 
system. A good screen design, like a good form design,“1s an important 
instrument for steering the course of work. 


: : ien ah uid penedo 
Most of the principles discussed for good form design sho 
good career denA as well. The format of the screen should resemble 


rr j Te i2 „Å 


the form as closely as possible. shiek z ae Sy 
Four guidelines for screen design are important: 


1. Keep the screen simple.. hepna 1G 
. is necessary for the 


The VDT screen should show only that data which 
Particular action being undertaken. 


ee é i Desi 
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2. Keep the screen presentation consistent. 


A consistent screen design is necessary for a good screen design. 
If users are working from paper forms, screens should follow what is 
shown on paper. 


Screens can be kept consistent by locating information in the same area 
each time a new screen is accessed. : 


Information that logically belong together should be consistently 
grouped together: Name and address go together, not name and pin 
code. 


For example, the screen for railway booking should look similar to the 
reservation form being used. 


3. Facilitate user movement among screens. 


The third guideline for good screen design is to make it easy to move 
from one screen to another. iinit : ¢ 


Example : Hot Keys can be used for faster movement. Messages at the 
bottom of the screen. ‘a S$ z : 


4. Create an attractive screen. ~ = 


SS bee 


This is the fourth guideline for good screen design. If users find screens 
appealing, they are more likely to be 


> more productive 
> need less supervision: 


> make less errors: 


their attention. Like good 
advisable rather than jamming all the data poe of multiple screens is 


flow in the plan of your screens. to, Sne occ Use logical 
oo 
SS = = 
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6.2 Output Design 


One of the most important features of an information system for users is 
the output it produces. Output is information delivered to users through 
the information system. Without quality output, the entire system may 
appear to be unnecessary that users will‘avoid using it. Users generally 
merit the system solely by its output.In order to.create the most useful 
output possible, the systems analyst works closely with the user 
through an interactive process, until the result is considered to be 
satisfactory. 


Therefore an effective output design is an important feature of design 
specification. 


6.2.1 Objectives Of Output Design 


Since useful output is essential to gaining use and acceptance of the 
system, the systems analyst should try and -follow the following 
objectives which are useful for designing acceptable outputs. 


1. Design output to serve the intended purpose: - 
2. Design output to fit the user. | 
3. Deliver the appropriate quantity of output. 

4. Assure that output is where it is needed. 
5. Provide output on time. 


6. Choose the right output method. l 


vi ri my 
+, 


1. Design Output to serve the intended purpose . i 
All outputs should shave a, purpose: During the Boe ene aa 
analyst finds out the purpose of the output, The o eo it 
designed to meet those purposes. If the output 1s no aise 
Should not be created, since there are costs of time ie terials 
associated with all output from the system: 
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2. Design output to fit the user 


The analyst by using the fact-finding techniques discussed earlier, 


should determine what information to present, which the users will 


need and prefer. The output should be what the user wanted. 


The users of certain outputs could be external users. These have 
specific requirements governing content, format and media 
requirements that are unchangeable, for example. the monthly P.F 
statement, a copy of which will be required to be sent to the PF office in 
their standard specified format. No change to this format can be made. 


3. Delivering The Appropriate Quantity Of Output 


Part of the task of designing output is deciding what quantity of output 

is proper for users. The system analyst must provide what each person 

needs to complete his or her work. No one is served if excess information 
is given. : 


Incase there is a query request for an employee's yearly salary, then this 
could be displayed in the following manner ; rather than cluttering the 
screen with an entire year’s salary details, each of the twelve screens 
might provide a month’s salary details and the summary information 
available on separate screens. 


It is necessary to keep the decision maker in mind when deciding about 
quantity of output. They often will not need great amount of output, 
especially if there is an easy way to access more. High and low 
quantities of data also suggest whether print or display should be used. 


4. Making Sure The Output Is Where It Is Needed 


Most commonly outputs are either printed on p: i 
paper or di ed on 
screens. Outputs often have to be distributed to thi oe PN 


The increase in on-line screen-displayed output, that i $ 

7 , t is personally 
accessible, has. cut ‘down on the problem of distribution. Appropziate 
distribution is still an important objective for the systems analyst. 
To be used and useful, output must be i 

ul, presented to the t user. No 

matter how well-designed the reports are, if they are ie cea the 
person who requires it they have no value. 
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5, Providing The Output On Time 


One of the most common complaints of users is that they do not receive 
information in time to make necessary decisions. 


Some reports are required on a daily basis, some monthly, others. only 
annually and others as and when a request is made. Accurate timing of 


output can be critical to business operations. 
6. Choosing The Right Output Method 


Whether the output is a formatted report or a simple listing of contents 
of a file, a computer process will produce the output. 


System output may be: 
e Areport 


iC 


e -A document 
e A message 


Depending on the circumstances ead the content the output maybe 
displayed or printed. Output contents originate from these sources: 


e Retrieval from a data store 


¢ Transmission from a process or system activity 


freee ie r r 


° Directly from an input source. 


Choosing the right output method for each user and purpose is another 
objective in designing outputs. 


Simplicity, Attractiveness 


Ans: 1) Effectiveness, Accuracy, Ease to use, Consistency, 
2) Effective output design 


So a a O 
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3) a) retrieval from a data store b) transmission from a process of system activity c) directly from an 
output source. 
6.2.2 How To Present Information 
How the information is presented will determine whether the output is 
clear and readable, the details convincing and the decision making fast 
and accurate. We will now discuss guidelines for presenting tabular and 
graphic uunuwau01. 


Tabular Format 


Tabular format implies to a row-and-column format as shown in figure 
6.2. 


The word report’ normally suggests a tabular format to many people. In 
general, the tabular format should be used under the following 
conditions: 


e Details dominate and few narrative comments or explanations are 
needed 


e Details are presented in discrete categories 
e Each category must be labelled 


Totals must be drawn or comparisons made between components 
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Certain information in a tabular format is more important and should be 
more visible than other information. This will vary by application. In 
general, we can be sure that the following items should stand out: 

e Exceptions to the normal expectations 

e Major categories or groups of activities or entities 

e Summaries of major categories or activities 

ə Unique identification information . 

e Time-dependant entities 

These elements need to be distinctive, and the analyst must design 
tabular output to achieve this objective. Besides these others could also 
be added on depending on the application. 

In addition, information in a format details should be in a meaningful 
order ( i.e. highest to lowest value, or alphabetical order), making it easy 
to locate the most important details. 

It is easy to overcrowd the report with too many details. One of the most 
frequent user complaints is too many details; too little information or 
drowning in data, but starved for information.Therefore it is necessary to 
ensure that unnecessary details are avoided. 


Features that will enhance readability should be used. These could 
include: à ; 


> Limit the number of items on a page 
> Label all columns and added totals 

> There should be a meaningful order 
> 


In case a description is repeated, for example. i 
department is repeated, then state the ple, in figure 6.2 the 


once when a change occurs. dep Sename only 


> Add emphasis to the heading 
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> Adding sub-totals for each department and sorting thë 
employee names within the department enhances readability 


> Sub-totals are also called coritrol*breaks. These communicate 
information and add emphasis, both useful to the reader. 


> An additional space between groups helps better readability. 


Graphic Format 


Management presentations have been enhanced by graphic and visual 
for a long time. Low-cost but powerful computer software is available 
that will use data from existing database and produce high quality” 
charts and graphs. 


Graphic forms can be shown on video display screen prepared in several 
colours on low-cost printers, drawn by computer driven plotters. 
Graphics enhance information presentation, but at the same time, few 
are willing to accept computer generated graphics as a replacement for 
traditional reports. i 


6.2.3 Designing A Printed Output Layout.. i 


Printed output commonly called a hard copy are normally required for 
the following reasons: 


> need to mail a document to an external user 


> printa record of data or a report of information to several 
persons simultaneously. cb. ai 


> acopy needs to be retained for a period of time i 


Whenever possible, the development of a computer joinain i men r 
should reduce, not increase, the number of prin ae Hse ae 
“rough the organisation. One well designed report may replace, F 
Poorly designed ones. 


cut 
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>} Printed Reports 


Printed reports vary in size. = 
Normally these standard sizes are used? 


9 1/2 by 11 inches 
11 by 14 7/8 inches 
8 by 14 7/8 inches 


These sizes are for continuos forms. When developing the printed 
output the size is required. The layout that is prepared should cove the 


required area. 
> Special Output Forms 


These are special forms pre-printed by a stationer. The variety is 
seemingly endless, since any colour or ink can be used. Many options 
on positioning of headings and logotypes are also available. 


The analyst lays out the content of the report on a pre-printed form in 
the same mzvmer as the computer-prepared report. Pre-printed forms 
convey distinctive corporate images through use of corporate colours 
and design. These form are extremely expensive compared to computer- 


pate report forms. Payslips are normally printed on pre-printed 
orms. . 


+> Developing A Printed Output Layout 


It is essential to have the right information and detail on a report as well 
as selecting the proper output medium. The design of printed output 


layout is the arrangement of elements on the output medium. The 


analyst has to first build a mock-up of the actual report or document to 


show how it will appear after the system is in ‘ 
should show the location and position of the hike oR; The layout 
e  :All variable information: 


This includes information that can v 


ehas: ary each time the report is printed 


+ Item details 
S a 
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» Summaries and totals 
» Control breaks 
e All constant information: 
This includes information that remains the same whenever the report is 
printed. To indicate constant information, the analyst writės it on the 


layout form, one character per space. 
The following fall under constant information: 


+ Headings 

+ Document names ant titles 

+ Corporate names and addresses 
+ Instructions 

+ Notes and comments 


As mentioned earlier, the layout is a blueprint. This will guide the 
construction of programs in the development process. 


Each variable must be accounted for in a program instruction. 
The layout forms tells us precisely: 


> Where the data will be printed 
> How far away it is from other details 


> Whether there is enough space to include ar n essential 
details without cluttering the appearance of e form 


+ Designing A Printed Output Layout z; 

It is necessary to determine the items that will be included ee rere 
before beginning the design of the layout. The reina ia ey 
Provides this information. The data dictionary ee tbat Report 
descriptive information such as the data item e ar pe L as 
ayouts can be formed manually using paper “27° Figure 
shows a sample report layout chart. 
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1. Headings 


All output produced from an information system should have a title. The 
procedure for designing headings is : 


> 


+ + + Ẹt 


“It is a good practice to use an underline, 


Enter the report title and heading on the layout using the specific 
columns in which you wish the information to appear. 


Centre the title. 
The layout includes a page number and date. 
This should appear on all the pages. 


The page number provides a quick reference for the users who work 
with data found at various locations throughout the report. 


After the entry of the headings is over, look at the actual contents of 
the report, the salary data. 


As the amount of space of each element to be printed is available in 


the data dictionary, the space each of them will occupy can easily 
be determined. - 


Now calculate the total space that will be used. 


130 spaces are available for printing. Once you know the total to be 
used then space the elements out within the 130 columns by 
leaving equal spaces between each element to be printed. 


Once you have determined the amount of Space available for each 
data element and the space to be left between each, then enter the 


column headings for each of the data elements that are to be 
printed. ; 


Pep aa part gL ths heading on gach page of the, 


dash, or some sitet 


symbol to separate the co. .mn headings from the start of the data. 


„We in figure 6.2 have.used a dash for this purpose. 


SSAD 144; 


Every column should have a heading that describes TESA 


The names ad words should be spelt out. Avoid abbreviations. 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Data Details 


D 


+ Enter the description of the data below the respective column 
headings. 


+ Use X* for alphabetic or Alphanumeric and 9’ for numeri¢ data. 


+ If decimal points, currency symbols or other special symbols 
will be used then mark them accordingly. 


>} Fora description which ‘is long, for sanp jtuployee name, 
you could either 


* fill up 30 X’s OR 


* mark the first and the last column with a X’ and 
connect the two with a straight line. OR 


* mark it as “30 a 


+ Although reports myc continue for pages, you ‘define the detail 
line only once. : 


+ The wavy line descending from each data item on the paper layout 
form indicates that it is repeated as many times as necessary on 
each page of the report. 


3. Summaries 


Some report ae specify summary information, column to is or 
sub totals. F 


+ These are marked in the same manner as just mentioned. 


artment wise summary for total 


+ The salary report contains a dep with a grand total for all 


earnings, total deductions and net pay; 
departments. 


i inthe same. 
+ The principle for showing the summaries remain 


> Label all titles and headings as you wish them to app 


ending on the field type. 


> : ? or 9’ dep ane 
Denote variable data by X’ o Input / Output Design 
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} Indicate the maximum length of the field. 


The steps mentioned above are used in the design of all outputs(screen 
as well). 


The principles for indicating field length, subtotals and other data are 
unchanged. 


4. Guidelines 


There are many guidelines that will make the analyst’s job easier and 
more important ensure the users of receiving an understandable report. ay 
We have used several which are summarised here: 


@ Reports and documents should be designed to read from left 
to right and from top to bottom. 


= The most important items should be easiest to find. (employee 
number is the most important item in the salary report, since it 
identifies the employee. It is placed on the left margin. 


@ All pages should have a title and page number and show the 
data the output was prepared. 


@ All columns should be labelled. 
@ Abbreviations should be avoided. 
6.2.4 Designing Screen Output 


In section 6.1.4 we have discussed guidelines for designing i 
p . lzi a ui 
screens, the same guidelines also apply for designing screen R 


The contents changes. 

Screen outputs differ from printed outputs in the following ways: 
+ AVDT is not permanent. 

> They can be more Specifically targeted to users. 

+ Itis available on a more flexible schedule 


> Itis not portable 
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+ Screen outputs could be changed through direct interaction. 


» Screens require you to give instructions to the user on how to use 
the display. The user needs to be instructed on 


- which keys to hit when they want to continue reading further 
screens 


- how to end the display 
- how to interact with the display if possible. 
+ With printed outputs, you can assume that people know 
- how to search through a report 
- how to turn to the next page 
- what steps to take when finished with the report. 


+ Access to screen displays may be controlled through the use ofa 
password. Certain information could be kept hidden from certain 
users i.e. information not meant for a particular user need not be 
shown to him. This could be identified by the password. Further, 
certain users(again depending on the password) could be allowed to 
interact while others can only view the output. Whereas, 
distribution of printed output is controlled by other means. 


> Screen Design 


Visual Display Screens typically have 80 columns wn 24 uaea we w 
assume this standard size for our examples. AP Battont The 
information should read from left to right ana Titles and headings 
most important details should be eases to noS 


should be consistently positioned. 


In designing a screen we need areas for : 


1. Headings and titles 
2. Content of the display | 
3. Messages and instructions 


A son i ort. 
4. Sometimes explanations for information 1m toeren 


1L / Output Design 
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A status line provides the user with information about the program: 

For example, a sort routine is half finished, a report is printing and so 
on. 

The information need not be detailed, as it is only a reference. 


Information instructing the users how to proceed, is generally shown at 
the bottom of the screen. 


The principles of designing a screen layout chart, remain the same as 
that of the print layout chart. 


Exercise - 2 


Ans: 1) Headings, data details, summaries and guidelines 


2) 
Variable information Constant information 
Summaries, Totals, Control breaks, Headings, Document n i 
5 ames/titles, Notes, 
Separator Instructions z 
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Summary 


This chapter has covered elements of input design for screens and 


source documents. Six objectives are to be followed for well designed 
inputs: 


effectiveness 
Accuracy 
Ease to use 
Consistency 


Simplicity 


+ TY +e ee +e + 


Attractiveness 


The analyst should start by capturing only those items that must 
actually be input. In order to design useful forms the following four 
guidelines for form design should be followed: 


1. Make forms easy to fill out 

2. Ensure that the forms meet purpose for which t .ey are designed 
3. Design forms to assure accurate completion 

4. Keep forms attractive. 


Design of useful forms and screens overlaps in many ways, but there 
are some distinctions. Screens display a cursor which continually 
orients the user. The four guidelines for well designed screens are: 


x 


1. Keep screens simple : 

2. Keep the screen presentation consistent 
3. Facilitate user movement among screens 
4. Create an attractive screen. 


Proper flow of both forms and screens is important. 


3 : i elivered by the information 
Output is any useful information oF data del d by the nati 
yaa to a user. The analyst has six main objectives in designing 


output. They are: 


1. Design Output to serve the intended purpose. 
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2. Design output to fit the user. 
3. Deliver the appropriate quantity of output. 
4. Assure that output is where it is needed. 
5. Provide output on time. 
6. Choose the right output method. 


The information could be presented in a tabular format or graphic 


format. The word ‘report’ normally suggests a tabular format to many 
people. ` 
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Chapter 7 


Testing, Implementation & Maintenance 


At the end of this session, you will be able to: 

Know testing strategies, types of test data, and levels of testing 
Have an idea of verification and validation 

Know the importance of training 

Get an idea of the various types of conversion TEE 


Know what is systems maintenance 


YU Yy y yyy 


Know the details of documents that are output at different phases of 
the systems development life cycle | 


Know the importance of structured walkthroughs and when they 
should be conducted 


Y 


i -failure systems. However, even if 
properly followed, will produce low. 
techniques are followed, the analyst must not assume that ae 
necessary quality standards have been met. Quality Assurance 15s ng 
review of software products and related - SoS on anes T 
completeness, correctness, reliability, and maintaina ty. 
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7.1 Managing Quality Assurance 


Quality assurance is the review of software products and related 
documentation for completeness, correctness, reliability and 


maintainability. 


It also includes assurance, that the system meets the specification and 
the requirements for its intended use and performance. 


Quality assurance can be done by: 
> Testing 
> Verification And Validation. 
7.1.1 Testing- 


Testing is generally done at two levels - testing of individual modules 
and testing of the entire system (systems testing). 


During systems testing, the system is used experimentally to ensure 
that the software does not fail, i.e., that it will run according to its 
specifications and in the way users expect. 


Special test data are input for processing, and the results examined. A 
limited number of usets may be allowed to use the system so analysts 
can see whether they use it in unforeseen ways. It is preferable to 


discover any surprises before the o ization i 
and depends on it. rganization implements the system 


Testing is done throughout systems development i 

just at the end). It is always a good practice to Sica ata a 
different levels at various intervals, that is, sub-systems ee 
modules as work progresses and finally the system asa whole If this i 
not done, then the poorly tested system can fail after installation Ls 


Kee 
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Thorough testing of programs do not guarantee the reliability of 
systems. It is done to assure that the system runs error free. S5 


7.1.1.1 Testing Strategies 


There are two general strategies for testing software. ‘This section 
examines both the strategies of code testing and specification testing. 


a Code Testing 


The code testing strategy examines the logic of the program. For this 
testing method, the analyst develops test cases that result in executing 
every instruction in the program or module, that is, every path through 
the program is tested. say 
A path is'a specific combination of conditions that is ‘handled by the 
program. The testing of every path in the program is not always possible 
as there could be several thousands, and financial and time limitations 
will not permit this. Generally, all the frequently ‘used paths undergo 
testing. 


@ Specification Testing 


To perform specification testing, the analyst examines the program 
specifications wherein states what the program should do and how it 
should perform under various ‘conditions. Then, test cases are 
developed for each condition’ or combination of conditions and 


submitted for processing. 


ini : nm determine whether the 
By examining the results, the analyst can del : 
program performs according to its specified requirements. This testing 
does not look into the program to study the code or path, it looks at the 
program as a whole. The assumption here is that, if the program meets 


the specifications it will not fail. 
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7.1.1.2 Types Of Test Data 
There are two very different sources of test data: 
> Live 
> Artificial 
Both have advantages and disadvantages. 
Using live test data 


Live test data are those that are actually extracted from organization 
files. This shows you how the system will perform on typical data. 
Although, the data may be the best, it is difficult to obtain sufficient 
amounts to conduct extensive testing. All combinations and conditions 
of the system are not tested with this data. This may not contain values 
that may cause system failure. 


Using Artificial data 


Artificial test data are solely for test purposes. They are to be generated 
to test all combinations of formats and values. They are generated using 


the utility programs of the information systems. Using this type of data 
all logic and control paths through the program can be tested. 


po best aoe the artificial test data should be generated by persons 
other than those who wrote the programs. Automated t 
generators are also available. = $ aA 


7.1.1.3 Levels Of Testing 


As already mentioned, testing is carried out t di 
various intervals. at different levels and at 


r Unit Testing 
This involves the tests carried out on modules/program i 
up a system. This is also called as Program ee The . ae 5 


system-are the modules and routines that ~ 
to perform a specific function. are assembled and integrated 
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In a large system, many modules at different levels are needed. Unit 


testing focuses first on the modules, independently of one another, to 
locate errors. 


The programs should be tested for correctness of logic applied and 
should detect errors in coding. For example in the payroll system, all 
the calculations should be tested by feeding the system with all 
combinations of data. 


Valid and invalid data should be created and the programs should be 
made to process this data to catch errors. For example in the payroll 
system, the employee no. consists of three digits, so during testing one 
should ensure that the programs do not accept anything other than a 3 
digit code for thc employee no.. 


Another e.g. for valid and invalid data check is that, in case a three digit 
no. is entered during the entry of transaction, and that number does not 
exist in the master file, or if the number entered is an exit case, then 
the program should not allow the entry of such cases. 


All dates that are entered should be validated. No program should 
accept invalid dates. The checks that need to be incorporated are : in 
the month of Feb the date cannot be more than 29. For the months | 
having 30 days one should not be allowed to enter 31.” 


All’ conditions’ present in the program should be tested. Before 
proceeding one must make sure that all the programs are working 
independently. 


2 Systems Testing 


When unit tests are satisfactorily concluded, the system as a com, siete 
entity must be tested. At this stage, end-users and operators pagim 
actively involved in testing. While testing one should also test to fin 


discrepancies between the system and its original Seas tn 


Specifications ‘and systems documentation. 


For example, one module may expect the none items for eee 
number to be numeric field, while other piod Sah ts error, but the 
character data item, The system itself may not S E EA 
output may show unexpected results. A shot wees eee field. If 
stored in one module, using the employes panes tation that it will be a 
this is later Sought on retrieval with the expec i ! 
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character field, the field will not be recognized and the message 
REQUESTED RECORD NOT FOUND will be displayed. 


Systems testing must also verify that file sizes are adequate and that 
indexes have been built properly. Sorting and reindexing procedures 
assumed to be present in lower-level modules must be tested at the 
systems level to see that they in fact exist and achieve the results 
modules expect. 


7.1.1.4 Special Systems Tests 


There are other tests that are in a special category as they do not focus 
on the normal running of the system. They are listed below:- 


& Peak Load Test 


This is used to determine whether the system will handle the 
volume of activities that occur when the system is at peak of its 
processing demand. For instance when all terminals are active at 
the same time. 


This test applies mainly for on-line systems. For example, in a 
banking system, analyst want to know what will happen if all tellers 
Sign on at their terminals at the same time before start of the 
business day. Will the system handle them one at a time without 
incident, will it attempt to handle all of them at once and be so 
confused that it locks up’ and must be restarted, or will terminal 


aam be lost? The only way sure way to find out is to test for 
i 


@ Storage Testing 


n one may discover that, 


there is not enough storage capacity for transactions and master file 


records. 
2 Performance Time Testing 


This test refers to the response time of th 


a F E e syste i i 
Perfomance time testing is conducted phor fe maps ee 
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determine how long it takes to receive a response to a inquiry, make 


a backup copy of a file, or send a transmission and receive a 
response. 


This also includes test runs to time indexing or resorting of large 
files of the size the system will have during a typical run or to 
prepare a report. A system may run well with only a handful of test 
transactions, may be unacceptably slow when fully loaded. This 
should be done using the entire volume of live data. 


@ Recovery Testing 


Analyst must never be too sure of anything. He must always be 
prepared for the worst. One should assume that the system will fail 
and data will be damaged or lost. Even though plans and 
procedures are written to cover these situations, they also must be 
tested. 


æ- Procedure Testing 


Documentation and run manuals telling the user how to perform 
certain functions are tested quite easily by asking the user to follow 
them exactly through a series of events. 


It is surprising how not including instructions about aspects such 
as, when to depress the enter key, removing the diskettes before 
putting off the power and so on, could cause problems. This type of 
testing brings out what is not mentioned in the documentation, 


and also the errors in them. 


@ Human Factors 


i essing, the screen goes blank, the operator may 
In case e aoe what is happening can he could just about do 
anything such as press the enter key a number of times, or en 
off the system and so on, but if a message 1S fae bead atten 
the processing is in progress and asking the operator to wait, 


these types of problems can be avoided. 


Thus, during this test we determine how users will use the system 
when processing data or preparing reports. 
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Exercise - 1 


related documentation fc 


„and 


5. There are other tests that, are in 
not focus on the normal running: 


Ans: 1) completeness, correctness, reliability. and maintainability. 
2) Testing . Verification & Validation 

3) Live data, Artificial data 

4) Unit tests, system 

5) Peak load test, Storage testing, Performance time testing, Recovery testing, Procedure testing, Human 


factors. 
7.1.2 Verification And Validation 
Verification testing runs the system in a simulated environment using 
simulated data. This simulated test is sometimes called alpha testing. 
The simulated test is primarily looking for errors and omissions 


regarding end users and design specifications that were specified in the 
earlier phases but not fulfilled during construction. 


The beta test sites use the system in day-to-da iviti 
t y activities. They process 
live transactions and produce normal system output. The system k live in 
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7.2 Implementation 


After proper testing and validation, the question arises, whether the 
system can be implemented or not. Implementation includes all those 
activities that take place to convert from old system to the new. , 


The new system may be totally new, replacing an existing manual or 
automated system, or it may be a major modification to an existing 
system. In ‘either case, proper implementation is essential to provide a 
reliable system to meet organization requirements. Aa >; 


m 
ťa 


f 


7.2.1 ‘Training — 


A well designed system, if not operated and used properly could fail. 
Training the users is important, as if not done well it could prevent the 
successful implementation of an information system. i RSA 


Throughout the ‘systems’ development ‘life cycle the user has been 
involved: By this stage the analyst should posses an accurate idea of the, 
users that need to be trained. They must know what their roles will be, 
how they can use the system and what the system will do and will not, 
_ Both system operators and users need’ training. During their training, . 
they need to be given a trouble shooting list that identifies possible 
problems and identifies remedies for the problem. They should be. 
advised of the common mal functions that may arise and how to solve 
them. 2 42 a00 << 
2 "NƏ 


The training should cover: 


e : ; armzU 
> familiarization with the processing system itself (that is the, ....;., 
equipment used for data entry or processing 


> training in using the application i.e. the sofware san boeit 
> good documentation is essential, but this cannot replace, tinod = 

trai ing. aa vrrolrusel x 
There is no substitute for hands on operation of the an While 
learning its use. ; i j jd pie odi sedo al ‘ 


iw arioe2riagino5 
7 > 
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7.2.2 Conversion 


Conversion is the process of changing from the old information system 
to the new or modified one. Conversions should be accomplished 
quickly as delays and long conversion periods cause frustration and the 
tasks of all involved including the analyst and user becomes more 


difficult. 


There are four methods available for conversion. There is no single best 
way to proceed with conversion. Each method should be considered in 
light of the opportunities that it offers and problems that it may cause. 
Some situations dictate the use of one method over others, even though 
other methods maybe more beneficial. Each of the four conversion 
methods are discussed briefly below: 


2 Parallel Conversion 

As the name implies, this refers to running the old system and the new 
system at the same time in parallel. This approach is most frequently 
used. This is the most secure method of converting from an old system 
to a new or modified one. 

Both systems are run simultaneously for a specific period of tme When 
the new system is proven to be functioning as it should, then the old 
one is stopped. This method is best used when a computerized system 
replaces a manual one. 

Advantages of this method are:- 


> Offers greatest security. In the case of problems or i 
errors in th 
new system, then the old system is there as backup. oe 


> Users are more at ease as they do not have to mak abru 
change to the new system. a m pA 


Disadvantages of this method are:- 
> Doubles the operating costs 
> Burdens employees involved with double workload 


> Incase the old system is not manual, then it js d; 
comparisons with old and new ou ares €n it is difficult to make 
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> Supposedly the new in an improvement on the old, therefore the 
outputs should differ. i 


> Employees faced with the choice between the two may opt for 
the old as they are more familiar with it. 


@ Direct Cutover 


Direct Cutover means that on a specified date, the old system is 
dropped and the new system is put into use. The organization now 
relies fully on the new system. For direct cutover also known as direct 
changeover, to be successful, extensive testing is to be carried out 
beforehand. Direct cutover is best used in cases where some delays in 
processing can be tolerated. i 


Advantages of this method are:- 

> Forces users to make the new system work 

>: There are immediate benefits from new methods and controls. 
Disadvantages in this method are :- 


> There is no other system to fall back on incase of serious 
problems or difficulties in the new system. 


> Requires most careful planning. | 
> Users may resent being forced into using an unfamiliar system 
without recourse. ona a 


> There is no adequate way to compare new results with the old. 


@ Pilot System 


the system is implemented in one part 
department. The users in this area 
a new system and that changes can 


In this method a working version of 
of the organization for example a 
typically know that they are piloting 
be made to improve the system. 
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Once the required changes are carried out and the system is complete, 
then it is implemented throughout the organization either all at once or 
phase by phase. Pilot approach is best used when new systems involve 
new techniques or drastic changes in the organization. 


Advantages of this method are:- 
> Provides experience to the users and operators 


> Provides live test data before implementation 


Disadvantages in this method are :- 


Incase implementation is not handled properly then users may. 
develop the impression that the system is not error free and may 
think it unreliable. : 


@ Phase-In-Method 


The Phase-in-method is used when it is not possible to install a new 
system throughout the organization all at once. Only one phase of the 
system is implemented at a time. The file conversions, training of 
personnel, or arrival of equipment may not take place all at.once: This: 
may force the staging of implementation over a period of time. This 


could be weeks or months. Some users may start taking advantage of 
the new system earlier. re 


s 


Advantages of this method are:- 
> Allows some users to take advantage or the System early 


> Allow training and installation without 
unnecessary 
resources. sect 


Disadvantages in this method are :- 


> Alo hase-in cause : 
_ Alene Phasen causes user problems whether the project goes 
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7.2.3 Conversion Plan 


This plan should: be formulated in consultation with the users. The 
conversion plan includes a description of all activities that must occur 
to implement the new, system and put it into operation. This includes 


identification of persons responsible and timetable for each activity that 
is to be carried out. ; 


During the planning of conversion, the analyst should form a list 
containing all tasks, including the following :- 


1} List all files for conversion. 
2. Identify all data required to build new files during conversion. 


3. List'all new documents and procedures that go into use during 
conversion. 


4. Identify all controls to be used during conversion. Establish s- 
_ > procedures for cross-checking the old and the new systems. 


5. Determine how team members will know if something has not been 
completed properly. 


6. Assign responsibility for each activity. ’ 


7. Verify conversion schedules. EA i 
The conversion plan should anticipate possible problems and ways to 
deal with them. sadi z aa289 > 


i Sissal 


af 


7.3 Systems Maintenance A hones asy msa iF 2: 


i ose’ design is comprehensive and 
rojected user neeas Ior Sev L 
farsighted enough to serve current and. proje : zea 
years t5 dae: a of the analyst's ee E E ee 
what those needs might ba sd eeit design, the easier it 
adaptability into the system. 5 ost will be low. Reducing the 
will be to maintainand the maintenan i ve software maintenance can 


maintenance costs is a major concern, anaes See 
prove to be very expensive. It is imparo S pay eee sre 
errors early on, as it is less costly than reman unnon n 


maintenance is necessary: a Testing, Implementation 


& Maintenance 


aot 
A system should be creat 
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Maintenance is performed most often to improve the existing software 
rather than to respond to a crisis or system failure. As user requirements 
change, software and documentation should be changed as part of. the 
maintenance work. Maintenance is also done to update software in 
response to the change made in an organization. This work is not. as 
substantial as enhancing the software, but it must be done. The system 
could fail if the system is not properly maintained. 

7.4 Documentation 

Documentation or Procedure Manuals explains how the system is 
designed and operates. Access to procedure manuals is necessary for 
new people learning the system, as well as a reminder to those who use 
the program infrequently. They may contain background comments, 


Steps to accomplish different processes, instructions on how to recover 
from problems, and what to do next if something isn’t working (trouble 


shooting). 
To be useful, manuals must be up to date. A good manual will be used 
repeatedly as a reference. As such, it needs to be organized in a logical 


way with careful thought given to the circumstances that would call 
forth use of the manual. . 


In general a good manual should be: 
> well organized 
> should be easy to locate needed information 


> all cases should be included 
> manuals should be written in plain English. 


Besides the manual’s organization and clari z 
be given to the-kinds of people who will be cane as oul 


Documentation is to be doné at various stages of the SDLC 


SSAD 7 164 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


1. Feasibility Report 


This report is the output of the feasibility study which is carried out at 
the onset of the system. It tells us that the system requested is feasible 
or not. The major purposes of this report are : S 


1. Identify the responsible users and develop an initial “scope” of the 
system. 


2. Identify current deficiencies in the user’s environment 
3. Establish goals and objectives for the new system. 


4. Determine whether it is feasible to automate the system and, if so, 
suggest some acceptable scenarios. 


This report contains a brief description of the current system and an 
outline of the proposed system.“ 


2. Functional Specifications 
This is the output ‘of the requirements analysis phase of systems 


development life cycle. The feasibility study forms the basis of this 
report. This document contains the following details : 


Describes ‘what’ system should do 
It contains : 
> Detailed DFDs: All levels of Physical and logical DFDs 


> Data dictionary: detailing the data in the system 


> Input formats 


e copy of the input documents and screen output 


e specifications such as general format of all the screens 


© Source of Data - which specifies type of input form 
needed by the system 
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Available From - Gives sources from where inputs 
are to be collected 


> Output specifications 


List of reports required and their details such as : 
Report name and object of report . 
Frequency - how often it is used 

Period - period for which information is required 
Due Date - when the report is required 


Prescribed arrangement- Specification of the order in 
which information is required 


Unit - Specifies units of columns of the report 


Distribution - Distribution of the report to various department 
persons. - 


> Process specification - Decision trees, structured 


English, and decision tables that 
are used to describe the logic 
used in the processes. 


3. System Design Note 


should be covered in this document are $ 


This should give the details of the design of the system. The topics that 


> Scope ofthe system 


° systems limitations, systems objectives, maj i 
and constraints. me functions 


Structure charts 


Yv 


y 


Program pecans - a short description of what the 
program does, what are inputs to the program, out 

program, calculations if any, program code ane ie nS 
program codes could contain 
sections of the code. 


comments to explain complex 
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> Input layouts 

> Output layouts 

> Data dictionary 
4. User Manual 


This is a very important document. If the user/operator does not use 
the system in the proper manner, then the system could fail. This 
should detail out the procedural steps tobe followed right from the start - 
to the finish. It should also tell the users the difficulties that could crop 
up and how to overcome them. 


The back-up procedures should also be included so as no valvable data 
is lost. All screens should be included and should contain details of 
_What is to be entered at each stage. a 
The user manual should generally contain the e folowing 
> Introduction 
e what the system dor- 
* system functions 
e users of the system 
- system developers 
- system and configuration required 
° limitations 
- size limitations 
- assumptions 


> Principles And Procedures F 


- General 
- Outputs 
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- Inputs 
- General procedures 
- Start up/ sign on 
- Backup 
- Shutdown 
- Formatting disks 


> Tutorial - step-by-step walkthrough of example functions to be 
illustrated in the example 


> Reference 
e For each function 
¢ Function description \ 
¢ How and when used 
e Structure of command or screen 
¢ What happens 
e How to use 
e Errors and what to do 
e Examples 
> For each error 
e How recognized — 
e Meaning 
e What to do about it 
> Appendix 
How to install the system before first use. 
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7.5 Structured Walkthrough / Formal Technical Reviews 


A structured walkthrouglt is a planned review of a system or its software 
by persons involved in the development effort. The purpose of 
walkthroughs is to find areas where improvement can be made in the 
system or the development process. A walkthrough should be viewed by 
the programmers and analysts as an opportunity to receive assistance. 
As users and developers are involved in walkthroughs, the concept 
recognizes that systems development is a team process. 


The structured walkthrough should be used throughout the systems 
development process as a constructive and cost-effective management 
tool, after the detailed investigation( analysis review ) following design 
(desiga review), and during program development ( code review and 
testing review). 


All walkthroughs includes documentation that participants read and 
study prior to the actual walkthrough. 


o Analysis Review 


This is conducted to examine the functional specifications of the 
system, which is prepared after the analysis phase of the SDLC. This 
walkthrough is aimed at examining the func.’ons, “activities, and 
Pivcesses that the new system will handle. It emphasizes the 
iniormation and processing requirements the proposed design should 
handle. If there are inconsistencies among the requirements stated by 
the users and those the analyst is proposing to meet through the new 
system or if there are vague specifications, the walkthrough should 


uncover them so they can be dealt with. 


° Design Review 


i design specification for 
Design reviews, as the name suggests, focus on j i 
mecting previously identified yatea, cn be communicated 
supplied about the design prior ) : . 
Gaia stoned charts, N-S flowcharts, screen designs, input formats, 


output formats, document layouts. 
The purpose of this walkthrough is to determine whether the proposed 
design will meet the requirements efiechyay and eee y. athe 
participants find discrepancies between the design uirem 
they will point out and discuss them. ; z 
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e Code Review 


A code review is a structured walkthrough conducted to examine the 
program code developed in a system, along with its documentation. It is 
used for new systems and systems under maintenance. This does not 
deal with an entire software system, but rather with individual modules 
or major components in a program. 


e Post-implementation Review 


After the system is implemented and conversion is complete, a review of 
the system is usually conducted by users and analysts alike. Not only is 
this a normal practice, but it should be a formal process to determine 
how well the system is working, how it has been accepted, and whether 
adjustments are needed. 


The review is also important to gather information for the maintenance 
of the system. Since no system is really ever complete, it will be 
maintained as changes are required because of internal developments, 
such as new legal requirements, industry standards, or competition. 
The post-implementation review provides the first source of information 
for maintenance requirements. 


Exercise - 2 


rons involv 
Se cen 


of systems development life cycle 
4. 3 H S >, ad $ ois ` 


Ans: 1) System, onc part. / a part. system 
2) Structured walkthrough 
3) Functional specification 
4) Documentation and Testing 
5) Conversion 
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Summary 


The quality of an information system depends on its design, 
development, testing and implementation. z 


Quality assurance includes testing to ensure that the system performs 
properly and meets its requirements. 


Special cases of testing are validation and verification. The purpose of 
testing is to find errors, not to prove correctness. Test cases, using live 
or artificial data, are processed by the software, and errors are reported. 
Six special tests are : 

peak load test : 

storage test 

performance time test Sa 


recovery test 


+ + + F ¥ 


procedure test 


+ human factors test 


Each focuses on finding operation flaws in the system to prevent failure. 
Both live and artificial data are used to test the system. 


Implementing a system, whether a new or modified one, consists of 


three primary activities of 
+» t . ` 
+ conversion 


> reviews. 


Both users and operators need to be trained welson henya 
function as it should. 


Conversion is the process of changing fon an old 
It must be carefully planned and executed. 


system to a new one, 


—_—<$<<<<———_ —— 
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& Maintenance 
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Four methods are common: 
1. Parallel systems 

2. Direct cutover 

3. Pilot approach 

4. Phase-in 


Maintenance is performed to update software in response to the 
changing organization. ' 


Procedure manuals explains how the system is designed and operates. 
After the system is implemented and conversion is complete, a review of 
the system is usually conducted by users and analysts alike. 


A structured walkthrough is a planned review of a system oi its 
software by persons involved in the development effort. The purpose of 


walkthroughs is to find areas where improvement can be made in the 
system or the development process. 
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Appendix - A _- 


Case Study - Payroll System 


For our case study, we have chosen the payroll system of ABC Co. Ltd., 
which is a very familiar and simple system. Reference to this case will 
be made through out the book. 


a- Organizational Overview Of ABC Co. Ltd. 
“Payroll System” for ABC Co. Ltd. 


ABC Co. Ltd. is the only sales outlet in Bombay for certain consumer 
goods. It basically consists of three departments. 


1. Sales department: Employees of this department are involved with 
the order processing system of the company. They carry out all, 
the sales activities. : 


2. Accounts department : This department is involved with all the 
financial accounting aspects of the company. 


3. Administration department: The major activity of this department, 
is payroll processing of all departments, and recruitment of new 
personnel. a 


One of the jobs of admin department, is to calculate the payroll of the 
entire company. This so far is being done manually. The admin manager 
finds it very time consuming and feels that. this system should be 


automated. 


a Current manual system 


i t maintains thr eparate employee 
At dmin. department maintains three separa 
Sete ae of the fie departments of the company. The payroll 
is processed separately for each of the three departments. 


As and when any new employee joins, the Sa ade Jonnognteining 
all the employees standard details are aent R e admin. se = ep ih 
details are entered in the respective departments speis Tea Bs 
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A few months ago, a particular new employee - Anil’s, details from the 
appointment form were entered by the admin. clerk Joe, in the sales 
department register instead of the accounts department register. This 
mistake was realised after the entire processing was-complete. When 
the accounts department could not locate Anil’s payslip, they 
approached the admin. department. Joe, who had actually entered the 
register was absent. Another clerk Kumar, denied receiving Anil’s 
appointment form. He checked the accounts department’s employee 
register, and argued that if it had come, then the details would have 
been written into this register. The details were finally entered in the 
accounts department employee register, and the payslip for Anil was 


prepared. 


After a week, when Joe resumed duty, he was informed by Kumar as to 
how he had to oblige the accounts department by preparing Anil’s 
payslip after all the work was done. At that time Joe realised his 
mistake. He then had to cancel the information from the sales 
department employee register. Anil’s payslip which had actually been 
prepared and sent to the sales department was found lying on the desk 
of the sales clerk, who distributed the payslips. 


Just as the appointment form is sent to the admin, any changes in the 
employee details are also sent by the respective departments, and these 
changes are incorporated in the respective registers. 


By the 20th. of every month, the departments send in their attendance 
registers and O.T registers. The accounts department in addition, sends 
in the advance salary voucher details of all employees. . 


Having completed this, the payroll of each de | 
separately using the employee register details, ars absent details: roe 
OT hours and advance salary details, the monthly payroll statement for 
each department 1s prepared: This Statement is used básis fi 
preparing payslips, bank statement and Salary summary sisi aa or 
ements. 


SID) ee Ee a cr 
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Again there are a number of instances when: 


1. The figures appearing in the payslips do not tally with the payroll 
statement or the bank statement. I HOIS 


2. The figures appearing in the bank statement are wrong. 
3. The salary summary statement does not tally. i 


All this causes a great amount of chaos and confusion every month. All 
these problems were reported to the management on various occasions. 
It was finally decided to computerise the Payroll Monitoring function of 
the company. ; 


‘Success Consultants’ were entrusted with the development of the entire 
Payroll system of the company. They were asked first to carry out a, 
feasibility study and hand over a feasibility report to the management. 


Guidelines For Preparing A Feasibility Report For The Automation 
Of The Payroll System For ABC Co. Ltd. © 


@ Identify the Responsible Users and Develop an Initial ‘Scope’ of 
the system q ; 


The analyst must identify two specific groups of end-users: 


a. Those who uae the system. ‘In this case the officers and clerks who 
actually collect the data and calculate the payroll. 


b. Those affected by the inputs’and outputs of the system in study. In 
this case the Accounts department who should receive the accounts 
statement, and all those in the admin department who are involved 


with the inputs and outputs. 


To develop the initial scope of the system you need to get a broad idea of 
the system in study. In this case we can identify the main process as 
‘the payroll monitoring process’, which gets its inputs from the three 
departments of the company, which’ are the sales department, accounts 
department and the admin department. The outputs of the systems are 


sent back to the respective departments. 


initi i -which is a 
Besid d to develop an initial context diagram -which 1 
siasols deta oe diagram in which the entire: system is ea by a 
single process. (The context diagram 1s deseribonl ile ree 2): 
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~a Identify current deficiencies in the user’s environment 


As the payroll processing is being done separately for each of the 
departments, there is duplication of registers, and processes. 


As there are separate registers maintained, very often the entries are 
entered in the wrong registers, causing duplication of work and 
confusion. 


Errors in calculation result in, employees being wrongly paid, which 
need to be rectified in the following month. 


Payslips and all the required reports have to be typed out. This is not 
only very laborious and time consuming but there are a number of 
errors found. Very often the statements do not tally. 


2 Determine Objectives forthe new system 
Here we will briefly list the functions of the new system. 
> Maintenance of a employee details in a central location. 
Entry of new employee details. 
Updation of old employee details. 
Maintenance of a transaction details, and calculation of the days 


absent and Total OT hours of the month using the attendance 
details and daywise OT details obtained from the departments. 


Vv 


> Maintenance / check list printing o f current month’s transaction 
details. Si 


> Calculation of payroll and generation of the payslips. 


>» Generation of monthly reports : 
- Payslips 
- Cheques 
- Bank Statement (Payment advice) 
- Salary Summary Statement 
- Accounts Statement ( for accounts) 
- PF Statement 


> Generation of Yearly Reports: 
- Consolidated salary statement 
- Bonus Statement 


Peo 
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> Adhoc reports ( as and when required) 
- List of employee of particular grades 
- List of employees ‘whose basic salary is.between the’ 
given range. 


@ Determine whether it is feasible to automate the system 


The Analyst discusses goals and objectives for the new system in a 
review with the admin. manager, officers, clerks handling the payroll 
and the company manager. 


The admin manager considers the following three major areas to 
determine the feasibility of this project. 


Technical feasibility : He, determines whether the current level of 
technology can support the proposed system. ABC Co Itd., already has 
hardware installed. This, at present is being used by the accounts 
department. They have agreed ‘to ‘Spare one terminal to the admin 
department during their processing time. The current set up is 
sufficient for the processing of the payroll once a month and even for 
the adhoc reports as well as annual reports. à f 


Economic feasibility: He measures the cost effectiveness of the project. 
He now need not invest in the hardware as it is already available. He 
will still need to consider the time spent by the systems analysis’ team, 
the cost of doing a full systems study, cost of employee's time involved 
in the study, cost of the development of the software which has been 


entrusted to ‘Success Consultants’ . 


department themselves have made the request to computerise the 
payroll system. They are very keen to see it operational. 


should go ahead, they request ‘Success 


On having decided that they Analysis and Design of the company’s 


Consultants’ te carry out the 
payroll system. 
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Data Flow Diagrams 


Physical Context Diagram For Payroll Monitoring System 


The DFD showing the general i.e. top layer of the system is called the 
‘Context diagram’ . 


CONTEXT DIAGRAM FOR PHYSICAL PROCESSING OF SALES DEPT 


New 
‘Employee: Em, 


Í Fig 2.1 
Figure 2.1 shows the Physical Context Di i - 
payroll monitoring system at a very general oe describes the 


` 


> The context diagram i 
entities. agram consists of only one process, data flows and 
> The single process in figure 2.1 is ‘Payroll Monitoring System’ 


> The context diagram defines the 


the boundaries. system in study i.e. it determines 


> Each arrow, representing data i 
being used. ting flow, is labeled to show what data are 
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> New employee gives the new employee details and the employee’s 
bank details to the system. pee eh 


> The respective departments feed the system with the O.T details, 
attendance details and employee details which are to be updated. 


> The accounts department give the advance salary details. 


> The accounts department receives the accounts statement from the 
system. 


> The salary statement is received by the respective department. 
> The bank receives the bank statement. 
> The employees receives the payslips. 


> When data moves to a process ( i.e. data serves as input to the 
process) the arrow points towards the process to reflect the 
input. i 


> When the process produces data, the arrow points away frum the 
process reflecting the output. 


Developing the First Level Physical Data Flo'7 Diagram For Our 
Payroll Monitoring System 


The description of the payroll monitoring in the context diagram 
requires more details. We, now have to describe the system as we 


understand it at level 1. 


i i l i Diagram of the 
Figure 2.2 shows the First Level Physical Data Flow 
payroll calculation of the Sales department of ABC Co. Ltd. 


for the other two departments of the company. 


The same is applicable z 
(only the depane name will.vary). As can be seen, this level of the 


DFD contains five processes. 
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FIRST LEVEL PHYSICAL DFD FOR PAYROLL CALCULATION OF SALES DEPT 


D| Employee Regst 
OF Sales Dept. 


Entry of New | New Emp. Details 
employees 
details by 


Appointment Form 


| Admin clerk 


Sales į 
o—— > i 
| dept. /Emp, Detailsto be: 7 ted e OA 
{ | 


dept. 


| | ; : —— e 
| Sales OT. Details Transaction list of 
| Dept. j Attendance detaiy (Obtain month's} Months transaction | Sales dept. 
ars z uansactions of il 
detai S xe 

sales dept R 
acous ——_————=—*\ _ ) O 
Dept | Adv. Salary Vouchers 


Employee Register 
Of Sales Dept 


eae t e 


Payroll of Sales 
Dept. 


statement of 
Sales dept. 
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The following is seen in the DFD. 


> The Employee Data from the filled appointment form obtained from 
the, new employee is entered into the respective department’s 
employee register by the admin clerk. 


> Admin clerk makes changes in the employee register wherever 
required. 


> After obtaining the month’s attendance details from the attendance 
register, day-wise O.T data from the O.T register and the advance 
salary form the advance salary, vouchers which is got form 
accounts department, the month’s transaction list is written out. 


> Now using this transaction list and the details from the employee 
register the payroll of each employee is calculated and stored in a 
payroll statement of the month. : 


> The payroll statement forms the basis for typing out the payslips 
and the bank statement and salary statement. . 


> The payslips are handed over to the employees of the respective 
departments and the bank statement is sent to the banks. 
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Second Level Data Flow Diagram 


We have just seen and discussed the First Level Physical DFD. From 
that we learn that the processes need to be exploded in the sense, need 
for more detail is required to get a clearer idea of the processes. We need 
to draw lower levels of the DFD to obtain this. Going from higher level to 
lower level is called ‘exploding’ a data flow diagram. 


SECOND LEVEL DFD FOR OBTAINING MONTH'S TRANSACTIONS OF SALES DEPT. 


Days Absent [ Employce-wise 


\ 
eee | | 
Attendance Register (Calculauon of } days absent list 
les 7 days absent by k 
pdmun clerk 


= 


Calcutauon of j Total OT hours: OT hours list of 
jow OT Hrsj PPTA " sales dept. 
ea ofeach emp | 


Of sales dept} 
Me 


[Accounts 
| Dept. | Adv. Salary 
Vouchers Transaction list of 
Fig. 2.3 
an e a a ee OOO 
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Fig 2.3 shows the Second Level DFD for ‘obtaining month’s transaction’ 
process for payroll calculation. From this we can gather :- 


> That the admin clerk gets the attendance register from the 
respective department and calculates the days absent of each 
employee. 

> 


He also gets the day-wise O.T register and totals the O.T hours of 
each employee. 


> The accounts department supplies the admin. clerk with the 
advance salary taken details through vouchers. 


> Having got this he makes out a ‘month’s transaction list 

containing days absent (if any), total O.T hours and advance 
salary taken for each employee. 
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Figure 2.4 shows the Second Level DFD for ‘Calculation’ process of the 
payroll system. From this we gather:- 


> That the admin clerk checks the employee. register and by- 
passes all exit cases. 


> For each non-exit case he then checks in the transaction list, if 
there is any transaction for that particular employee. 


> He then uses the data present in the employee register and the 
transaction list (if data for the employee present) to calculate the 
payroll for the month. The month’s payable data is thus obtained 
and stored in the payroll statement. 


Figure 2.5 shows the logical Context Diagram For Payroll Calculation of 
the full company. 


‘LOGICAL CONTEXT DIAGRAM FOR PAYROLL PROCESSING 


Payroll 
1 Monitoring 


Fig 2.5 ; 
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Bank Filc 


Bank Details 


Current Emp. 
* Master Details 


Employee 
Master file 


Updated Emp Master Details 
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Data Dictionary 


Dt-of-Join DATA ELEMENT 
Short Description _ This element describes the date when the employee 
joined the 
Organisation 00 Type: A AN'N D 
Date 
Aliases (contexts) 


IF Discrete IF Continious 


= 
Values 
Typical 
Value _1/09/90 


Internal Representation 


Rae SPIO | Ea 
ee APERON OURENSE 
eT e Length RS 
E o a aooe fon ania | SSO 


(If more than 5 values, continue 
on reverse or give. refernce to 
separate sheet ) 


Other editing information _The date type can be changed.to o.ther. 


formats like dd/mm dd/mm etc. 
Related data structures / elements 


Se e a a i 


2.9 Specimen form for recording data elements 
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DATA FLOW 


New Emp details 


Source ref: Description : Employee 
Destn. Ref: Description: Employee Register 


Expanded description : Employee details like: Name, date of joinng, 
dept, grade, salary details, bank details are entered into the 


_employee register 


Included data structures : Volume Information 


Employee register 
Volume increases as and 


when employee joins. Does 
not decrease when employee 
exits, as the record is not 
deleted. (Exit flag is inserted) 


Fig 2.10 Specimen form for recording data flow 


Transaction List DATA STORE REF : 
Description : Month’s Tranasction details 


Data flows in : Data flows out 


Overtime , attendance and__ Consolidated transaction of the month 
ad: details 


vance sal 
-advance Salary detas __ SEE 
naa a 
SS Se eee 
a EE 


contene : Immediate access analysis is to be found 
Employee number, 

Transaction code 

Transaction value Physical organisation : Sales Department 


Fig 2.11 Specimen form for recording data store 
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Description : Maintain Master Employee Pay Details 


New Employee 
details 
bank details 


required details need to be 
entered. A new record is 
written. 

For old employees, details 
to be changed are updated 


eraployee master 
file 


Current employee 
details 
to be updated 


Physical ref : 


Full details of this logic can be found in : (location where you may list 
the entire logic in detail). 


Fig 2.12 Specimen form for recording process 
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Wormalization 


Unnormalised Employee Record 


Jacob Rego ae 


A02 Suren Gupia 


Basie [DA [HRA] 


2500 
S000 


Bank Details 


[Code [Name J Address | ACN. 
[or [Sei [Coma [SB 
[03 [Canara | Andhe | 


Figure 3.3 Unnormalised Employee Record 


Figure 3.3 sho i 
TEP ws an unnormalized form of an employee record, this 
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Employee no., employee name, employee details ( department code, 
grade, date of joining, exit code and exit date), annual salary earned 
(MMYY , net paid ), bank details (bank code, bank name, address, 
employees A/C no) . : 


Here it is clearly seen that the employee’s annual salary earned details 


which are : Month and Year paid, net paid, are being repeated. 
Therefore this relation is not a first normal form. ; 


First Normal Form. - Employee Record 
Name Emp. | Salary 
details 


Bank 

Details _ 
Jacob Rego | J | ee 
ENNE 


Fig. 3.4 First normal form 3 


Figure:3.4 shows the normalization to first normal form for the employee 
record. 3 P 


As mentioned above the first normal form is carried out by removing the 

repeating group. In this case we remove the Annual salary earned items _ 
and.include them in a new file or relation called Annual Salary earned 

record. Employee number is still the primary key in the employee 

record. A combination of employee number and MMYY is the 

primary key in the annual salary earned record. 


for cord structures of fixed length: 
We e iere seer consisting of: Employee no., employee name, 
employee details ( department code, grade, date of joining, oat Ge 
and exit date), bank details (bank code, bank name, SS, 


employees A/C no) : 
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Annual salary earned record consisting of - employee no., month 
& year(MMYY) and net paid. 


Second Normal Form - Employee Record 
Emp.no. Emp. A/C No. | Bank 
details code 
[Aoi _[JacobRego_| |__| SB97S1 [OI __ 
| Suren Gupta | | 1970 03 


Annual Sal. Earned record 


Figure 3.5 Second Normal Form 


The three record structures that are created are : 


1. Employee record consisting of: Employee no A nam: 
: : + emplo > 
See TA if department code, grade, date of joining edt code 
and exi te), bank details (bank 
eG. (b code, bank name, address, 


2. Annual salary earned record consistj . 
& year(MMYY) and net paid. ag of- emplo = mo: —month 


2 m Sere of : bank code, bank name and bank 
dress. e attri : e 
Bank code. utes of this relation are fully dependent on 


The primary key of each of the record structures are underlined 


GR 
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Structured English 
Sequence Structures z 


Example : . 
Process to update a particular employee record as he has resigned. 


1. Get particular employee record 

2. Enter ‘1’ in Exit code data element 
3. Enter date of resigning in exit date. 
4. End of job 


This simple example shows a sequence of four steps. Note that none of 
the steps contain a decision or any ‘condition that determines whether 
the steps are taken. rE 


© Decision Structures 


The following example shows the nesting of multiple levels of conditions 
and actions for each decision point. 


If employee does not exist 
Else 
If grade < 20 
DA = 20% of basic ! 
HRA = 0 
Else 
If grade < 30 
DA = 20% basic limit to 600 
HRA = 400 
Else 
If grade < 40 
DA=0 ; 
HRA = 40% of basic 
Else 
DA=0 7 
HRA = 50% of basic salary 


End if 
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@ Iteration Structures 
Example: 


DO WHILE there are employees 
If employee does not exist 
Else 
If grade < 20 
DA = 20% of basic 
HRA = 0 
Else 
If grade < 30 
DA = 20% basic limit to 600 
HRA = 400 
Else 
If grade < 40 
DA=0 
HRA = 40% of basic 
Else 
DA=0 
HRA = 50% of basic salary 
End if 
End do 
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Decision Trees 


DA = 20% of 


HRA = 40% of 
basic 


Root 


DA = 0 
HRA = 50% of 


Figure 4.3 
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Figure 4.3 shows the process to arrive at the DA and HRA of an 
employee, based on the grade of the employee. Calculation should be 
done only for employees still existing is the company. The slab is as 
follows: 


Grade 10 - 19 DA = 20% of basic salary 
HRA = nil 
Grade 20 - 29 DA= 20 % of basic 
Hra = 400 
Grade 30 - 39 DA = nill 
HRA = 40% of basic 
Grade 40 & above DA= nil 


HRA = 50% of basic 
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Decision Tables 
Decision Table with Limited Entry table 
This decision table is made according to the example given in decision 
tree. We have arrived at this table after eliminating all the impossible 


situations, contradictions and redundancies. This has already been 
explained. à 


Decision Table with Limited Entry form 


Employce exists 

Grade between 10-19 
Grade between- 20-29 
Gradc between 30-39 


Grade greater than 39 


DA 20 % of Basic, HRA= 600 ~ ` 
DA 20 % of Basic , HRA = 400 
DA = 0, HRA = 40 % of Basic 

DA = 0, HRA = 50% of Basic 

Mo Calculation 


Table 2 i $ ` 


T Ae oy: saccimaple 
In a limited entry decision. table, the condition are expressed im 
Yes or No questions, whereas in a Extended Entry table conditions 
have more than two possible states. 


In the extended entry form, the condition is that, if an employee exists, 


z zœ in marketing department (“MKT”) he is eligible for 
ae Ercan pean? is based on the total sales made for the 


month and is calculated as follows: 


« « @ 10% : 
If sales >= 10000 then commission is 2 3 aT, 
if sales >=5000 and <10000 then commission 1s 10% 


if sales <5000, commission is 0 


The table is shown in table 3. 
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Employee exists Y Y Y Y 


Department MKT MKT ADM MKT 
Total sales 10,000 2000 - 5000 


Commission applicable 20% 0 


Table 3 


Note: n.a is Not Applicable 

The decision table above explains how the commission is given 
according to the sales per month. According to these conditions the 
actions have to be taken. In the: first rule, the person exists, he isin 
“MKT” department, and his total sales is upto 10000, so he is eligible for 
commission, he will get commission, 20% of sales amount: 


In rule 3, the person is in “ADM” department, so he does not have any 
sales figure, so he is not eligible for any commission as such. 


v: Mixed-Entry Form 


Now let us See an example of the mixed entry form, where there are 
various combination of conditions and actions taken. 


According to the company’s rules and policies, following are the 
conditions and actions to be taken 


1) For all employee in the grade 10-19 and those in marketing ) 
department commision is calculated as follows: ; 


If sales >=10000 then commission is 20% 
if sales >=5000 and <10000 then commission is 10% 
if sales <5000, commission is 0 


Ifthe person isin any other dep 


commission. ent then he isnot entitled for 
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2) Second condition is to check if the employee is supposed to pay 
income tax. This is done as follows: 


If the employee’s salary >= 50,000 - Tax applicable 
if salary <S0000 - Tax not applicable 


Tax is calculated for employees of all departments. 


Conditions and Actions 


MKT MKT FIN. FIN MKT 
Y Y Y Y Y 


Depariment 
Grade 10- 19 


Salary >= 50,000 p.a. Y N Y N N 
Salary < 50,000 p.a. - Y N Y Y 
Total sales 20000 10000 - - 3000 


20% 10% n.a n.a 6 
X - X = - 
8 xX < 


Commission applicable 
income Tax applicable 
Income Tax exempted 


ta 
* 


Takle 4 
The decision table in table 4 explains the following: , 


In the first rule, the person is in “MKT” department, the grade is 
beiween 10 and 19, and the salary per annum 1s more toan 50,000 and 
sales is Rs. 20,000. The action taken for this rul ` is - 20 % commission 
i- given because he is in marketing department aud he is applicable for. 


Income tax. 


In rule 4, the employee is in Finance (“FIN")department, grade is 
between 10 -19, and salary less than 50,000 per annum, so he is 
exempted from income tax, and he is not given any commission as he 1s 


not in marketing department. 3 
Se ng department, his grade is between 10-19, he 
peu ea be o a lay less than 50,000, he is not given 


commission as his sales is only Rs. 3000. 


ile design specifications are made. 
a ee beri a ade ie d module, and you can see how 
e is mad rding 


each table is designed and how actions are taken. 
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o- ELSE form 


The conditions for the ELSE form is that the employees of marketing 
department are given commissions according to the total sales done. 


The commission is given as follows: 


If Sales >= 10000 then 20% commission 

if sales >=8000 and sales<10000 then 15% commission 
if sales >=5000 and sales <8000 then 10% commission 
else 

if sales <5000 then 2% commission 


Sales >= 10000 
Sales >=8000 and <10000 


Sales >=5000 and <8000 


Table 5 


The Else form decision table shown below has an extra ELSE column. 


The ELSE is applicable for all marketing d 
have made sales less than 5000, ting department employees who 


The first rule tells us that the employee is in marketing department, his 


ea ; 
ža es amount is between 8000 and less than 10000 so he gets 15% 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Structure Charts 


ae Calling Module 


GET EMPLOYEE 
DETAILS 


Name No. 
temp Is OK. 


Called Module 


FIND EMPLOYEE 
NUMBER 


Figure 5.1 shows a structure chart 


In the figure 5.1, ‘GET EMPLOYEE DETAILS’ calls FIND EMPLOYEE 
NAME’. There is data passing between the two modules. 


o GET EMPOLYEE DETAILS sends data emp. no. to FIND EMPLOYEE 
NAME. 


e FIND EMPLOYEE NAME (having done its function) returns data 
Emp. Name to GET EMPLOYEE DETAILS, and 


. No. Is OK) to GET 
NAME also returns a flag (Emp. . 
i mno ee eras _ This is used to tell the calling module (caller) 


t everything went Use | e , 
Sane may send a flag saying Snvalid emp. No. 
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STRUCTURE CHART 


PERFORM 
PAYROLL 


Emp. no. 
Ss 
o_Emp. Name 
D> 
EN Net 
details Ns 


Print Reports 


Monthl 


Ste Pay 
Adv. 

Salary = 
Details N 
Calculate 
Earnings & 
Deductions 


Employee 
Details 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Appendix B- 


This appendix enumerates an additional example for normalization with 
reference to an input document. 


For this example we will consider the Purchase Order document, which 
is used to, place order on the supplier for the supply of cassettes. It has 
the following format: 


Purchase Order 


The unnormalized (UNF) form has the following data items: 
UNF 


PO-No i ali G i : li STS 
PO-date `. n Ga at a < REE TTR, in 7 
Supl-no A rode adi MOT MCT BUSA 
Supl-name PY Fa i : Ailing wolod n 
Address-line-1 
Address-line-2 
PIN Ba 
Class ‘ el 
Title y i 
Qty ae 
Rate 
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The UNF should also have a key. In the above example, PO-NO is the 
key. The keys are always underlined. Any derived/calculated items such 


as Value need not be listed. 
First Normal Form (FNF) 


Rule 1. Separate the repeating Group 


In the above UNF, items listed after PIN are repeating. Such repeating 
groups should be separated from UNF and written as a separate group 
with a key. This group should be related with the non-repeating group 
by attaching the key of the non-repeating group prior to the key of this 
group. Thus we have the following groups in the FNF 


PO-No 
PO-date 
Supl-no 
Supl-name 
Address-line-1 
Address-line-2 
PIN 


as non-repeating group and, 


as the repeating group. 


The repeating group has Class as the key. This canno i ivi 
F AS & - t be : 

repeating within the PO. Therefore if combined with PO-No which is the 

key See Pea EREA aE ieoup then it is unique. Thus, the. non- 

repeal group m the above two u ti 

given below will form the FNF. pedi e repedtingr group 

Po-No 

Class 

Title 

Qty 

Rate 
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Second Normal Form (SNF) 


Rule 2. Removal of data items which are not fully dependent on the 
primary key. 


The SNF will be as follows after applying the rule to the FNF 


PO-No 
PO-date - 
` Supl-no } 
Supl-name 
Address-line-1 
Address-line-2 
PIN 


PO-No 
Class 
Title 
Qty 
Rate 


Class 
Title 


i d key 
The title depends entirely upon the class and not on the compoun: 
PO-No#Class. Therefore it is separated with class as the key for the 
separated group. We then arrive at the above groups as SNF. 


Third Normal Form | | 
Rule 3. Removal of transitive dependencies 


i ined to check whether 

-key- attributes in each group are examine c 

heta ay inter-dependencies. If found, such dependent items as 

separated into a different group along area gaea Ha on aoe ne 

are dependent. This data item will form the ae ae EAS 

i ier Details depend on Supplier No. There 

e dependencia SER PO. The details of any super 

cannot be deleted from the supplier group until all the POs pertaining to 

that concerned supplier are deleted. ee : 
supplier whereas a supplier may suppiy 

POs. 
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Applying the above rule and considering transitive dependencies, we 
arrive at the following groups which are in TNF 


TNE 


PO-No 
PO-Date 
Supl-No 


Supl-NO 
Supl-Name 
Address-line-1 
Address-line-2 


Class 
Title 


All the Normal Forms (UNF thru TNF) are given below for reference 


UNF 


PO-No 
PO-date 
Supl-no 
Supl-name 
Address-line-1 


ENF 


PO-No 
PO-Date 
Supl-No 
Supl-Name 
Address-line-1 


SNF TNF 
PO-No PO-NO 
PO-Date PO-Date 
Supl-No Supl-No 
Supl-Name 
Address-line-1 
Address-line-2 Supl-NO 
PIN Supl-Name 
Address-line-1 
-PO-NO Address-line-2 
Class PIN 
Qty | 
Rate PO-NO 
Class 
Class Qty 
Title Rate 
Class 
Title 


Fn ee, 
dix i 


Appen 
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Appendix - C 


Task List For Each Life Cycle Stage 


This appendix outlines in detail the tasks and deliverables for each 
stage of SDLC. This may be used for reference or as a check list. 


Task List for the Feasibility Stage 


©% 
9% 
% 


Q 


Analyze proposed system and write system description 

Define and document possible types of systems 

Produce cost analysis of the proposed systems. Use data from 
any similar systems as a guideline. 

Produce estimate of system size, schedules and costs. Include 
a schedule for completion of all major deliverables. 

Define quantitative and qualitative benefits of the proposed 
systems. 

Produce initial pay back schedules. 

Produce a detailed estimate of costs, schedules, resources, and 
the like, for the next stage (requirements definition). 

Assign project manager(s). 

Produce feasibility study document . 

Present a feasibility study report to the management review 
committee for approval of a particular system. 


Task List for the Requirements Definition Stage 


4 


Define scope of the proposed system 


- Functions x 

- Users sn i ; 
- Constraints : ; 
Interview all current and proposed users to determine the 
following: ta 

- Use of the current system 

- Deficiencies in the current system 

- Requirements of the new system 

Having determined the above, document the current system 
in terms of : 

- Description 
- Deficiencies - . ao 
l XXXV Appendix 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


+ 


¢ 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Produce new system requirements document which should 
include the following : 

- ` Primary user i 

- Requirements (process and information requirements) 

- Resolution of current system's deficiencies 

Produce list of tangible and intangible benefits. 

Produce a detailed estimate of costs, schedules, resources, and 
the like, for the next stage (system specification), including a 
schedule for production of major stages' deliverables. ` 


Produce a revised estimate of costs, schedules, resources, and 
the like, for the remainder of the project life cycle. 


Produce the requirements definition document (this task may 
include the building of a prototype). 


Carry out final review of requirements definition document. 
Make a decision on whether or not to continue the project. 


Define the major responsibilities of the next stage. 


Task List for the System Specification Stage 


+ 


Define the type of proposed system by translating physical, 
environmental, and operational constraints into system 
characteristics (as far as possible at this stage). 


Draw up the outline of the proposed system. This includes 


translating user requirements from th i : 
i : e prev 
financial specifications. previous stage into 


Develop the system dictionary by describing all elements of the 
system including functions, and data (information). 


Review and expand cost-benefit analysis. 


z Updat - 
benefit analysis with new information. paee old. cost 
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% Produce a detailed estimate of costs, schedules, resources, and 
the like, for next stage (system design). 


® Produce revised estimate of costs, schedules, resources, and 
the like, for the remainder of the project life cycle. 


© Produce the system specification document. 
4 Carry out final review of system specification document 
© Review the decision of whether or not to continue the project. 


© Define major responsibilities for the next stage for team 
members, and others. 


Task List, for the System Design Stage 
4 Produce overall system design to include 


- Programs and major program functions 
- Functions and programs 
- Hardware and software environment 


% Carry out a search for suitable software packages which could 
implement some or all of the required functionality in a cost- 
effective manner. 


¢ Develop a detailed system design for each design alternative. 
Provide detailed system design documentation for the complete 
system . This will include 


- Updating the system data dictionary r : 
- Comparison of the design against system specification 
Documenting the required hardware and software 


environment 


¢ Update the cost-benefit analysis for each design lierne 
i wfound information. Review the analysis stage 
bee o E that expected benefits still exist and that 


the pay back period is still acceptable. 


ii Appendix 


XXXVI 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


© 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Produce a detailed and revised estimate of costs, schedules, 
resources, and the like, for next stage (program design and 
development). 


Evaluate the design alternative and:for each design alternative 
document the following: j 

- Ustr requirements being met by this alternative 

- Cost-benefit analysis and pay back schedules 

- Probable user acceptance level 

- Recommend the best alternative(s) 


Develop a test plan for the system by 

- Creating input test data 

- Preparing a list of expected output 
-  Préparing a list of test criteria 

-  Dé&veloping a system test schedule 


Identify the needs for user's training and documentation. Here, 
it is n@tessary to define an outline for : 


- Usgr documentation 
- Opérator manuals 
- User and operator training documents and schedules 


Produge the system design document. 
Carry out final review of system design document. 


Define next stage major responsibilities for programming and 
test teagan members, and others. 


FS a a 
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Task List for the Program Design and Development Stage 


4 Produce work plan: 


- Develop detailed list of tasks to complete development and 
testing of all system components 

- Produce schedules for all above tasks (a PC-based project 
management system could be useful for this) 

- Install progress and status recording procedures 

- Obtain approval of work plan from the project's 
management 

$ Produce detailed design for each program. 


$ Code, document, and unit test for each program. Carry out any 
and all necessary updates to the system data dictionary. 


@ Carry out integration test . Enter successfully unit tested 
programs into Integration Test Library. Carry out integration 
testing on each program. Document all integration test results. 


@ Finalize users and operators user guides and training 
manuals. 


$ Produce a detailed estimate of costs, schedules, and the like, 
for the next stage (system.test) . 


@ Produce a revised estimate of costs, schedules, resources, and 


Produce program design and development document. 


@ Carry out review of program design and ` development 
document. 


@ Carry out review of system test plans. 


@ Obtain required sign off for completed programs. 
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Task List for the System Test Stage 
¢ Following activities must be done : 


- Test system according to system test plan : 
- Check out operational use of users' and operations’ guides 


by using them to carry out the system test 
- Check out users’ and operators’ documents by using them 
to train the operators and user who carry out the system 


test 
- Document all system test results 


@ Review implementation schedule in terms of: 


- Availability of resources 

- Contingency factors that might affect implementation 
- Availability of third-party vendor support 

- Final review of detailed implementation schedule 


è Develop a contingency plan which includes : 
- Criteria of contingency 
- Identification of contingency resources 
- Timetable for recovery or abandonment 
+ Develop service level agreement which outlines: 
- User performance, accuracy, and volume criteria 
- Vendor support criteria like Mean time to Failure and Mean 
time to Repair 
- System quality criteria 
@ Produce the system test documents 
@ Review and approve such documents 
+ Approve system documentation like : 
- Program documentation 
- Operators' manuals 


- Users' manuals 
- Support documentation 
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¢ Approve implementation plan 


% Sign off fully tested system with all involved 
- System development sign off 
- Users' sign off 
- Operations sign off 
- Quality assurance sign off 
- Finance sign off 


Task List for the Implementation Stage 


@ Install new hardware and software (this can and should be 
done prior to this stage, preferably during system test). 


¢ Train first set of users and operators (this can also be done 
during system test stage). 


@ Develop contingency, recovery, and fallback plans (this can 
also be done during system test stage). 


$ Develop maintenance and release procedures and set up 
procedures for : 
- Regular releases of software (internal and vendor-supplied) 
- Emergency "fixes" 


è Carry out any data conversion required (this may be part of the 
operation of the new system) 


¢ Carry out installation of new system : 
- Immediate cut-over or 
- Parallel run or 
- Phased installation 


@ Plan and schedule the post implementation review and set 
criteria for : 
- System performance 
- System quality 
- User satisfaction a 
- Quality of user and operator manuals training 
- Ensure availability of required personnel and required 
documentation 
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@ Carry out post implementation review : 
- Create post implementation review report 
- Obtain signed approval of the report 
- Obtain letter of system approval 


+ Set up schedules for post implementation reviews, if necessary 
Task List for the Maintenance Stage 


è Implement changes to the system. 


$ To ensure that the system continues to meet the user's needs, 
use the service level agreement and perform 
- Regular reviews of requirements of service level agreement 


- Regular reviews of how system is meeting those 
requirements 
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Deliverables Required From Each Life Cycle Stage 


Deliverables to be Produced from the Feasibility Stage 


The feasibility study should include the following as its output : 


% 


© 


Brief description of the proposed system and its characteristics 
Brief description of the business need for the proposed system 


Proposed organizational structure defining key responsibilities 
of the project team 


Cost-benefit analysis, including a gross estimate of schedules 
and costs and a pay back schedule 


Proposed, tentative schedule for the delivery of key end 
products 


Deliverables to be Produced from the Requirements Definition Stage 


The output from this stage should contain the following : 


¢ Analysis of the current system (if any) 


4 


¢ 


+ 


Set of new system user requirements 


Summary of the proposed system (this can include a prototype 
of the proposed system) 


Estimates of the next stage and of the remainder of the project 


Deliverables to be Produced from the System Specification Stage 


The output from this stage is the system specification document, which 


contains the following : 
@ System description 
è Data requirement 
@ Network and telecommunication requirements 
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¢ System controls (password access, recovery and restart, etc.) 
¢ Revised cost-benefit analysis and pay back schedule 
@ Estimates of the next stage and of the remainder of the project 


Deliverables to be Produced from the System Design Stage 


The output from this stage should include the following : 


+ Management summary of the proposed system 


¢ Detailed system description, including descriptions and 
specifications of the following : 
- Programs, module libraries 
- Files and databases 
- Records and transactions 
- Data dictionary 
- Procedures 
- Schedules 
- Interfaces, both human and machine 


@ Description of proposed system controls 
@ Revised cost-benefit analysis and pay back schedule 


@ Recommended program design techni grammin 
ques, pro d 
documentation standards S Sen 


@ Recommended implementation techniques 
@ Preliminary system test plan 


+ Estimates of next stage and of the remainder of the project 
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Deliverables to be Produced from’ the Program Design and 
Development Stage 


The output of this stage should include the following : 


9 


4 


Detailed design documents for the system and for each 
program. 


Detailed design diagrams for the system and for each program. 
Detailed logic representation for each program. 
Detailed (program) documentation for each program 


Input/Output descrintigas (files, databases! transactions, 
screens, reports, and the like) 


Program source fisting: including embedded oneri 
Operator's guide (manuals) ‘for the cdiviplate ‘system: 
Results of unit tests for each program. 

Results of integration tests. 


User guide (manuals) for the complete system: 


Estimates’ of next stages, including the implementation 


schedule, conversion plans, _ and recovery and contingency 


plan. 


System test plan. 
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Deliverables to be Produced from the System Test Stage. 


The outputs from the system test stage should include the following : 


+ 


+ 


System test plans (updated). 


System test results. 
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è Results of variance with the expected results and plans for 
resolution of these variances. 


@ Results of documentation tests i.e. whether or not each type of 
documentation adequately served its intended purpose. 


+ Implementation schedules, conversion plan, and recovery, 
contingency, and fallback plan 


@ Service level agreement 
Deliverables to be Produced from the Implementation Stage 


The following deliverables should be produced by the end of the 
implementation : 


@ Full set of release and maintenance procedures. 


@ Detailed contingency, recovery, and fallback plan (if not 
already produced during the previous stage). 


@ Schedule and plan for the post implementation review. 

Post implementation review report. 

@ Signed letter of system approval. 

@ Detailed schedule for further post implementation reviews. 
Deliverables to be Produced from the Maintenance Stage 


The following deliverables should be produced during the maintenance 
stage of the system's life cycle : 


Detailed log of changes to the system. 


@ Copies of regular reviews and verifications of the service level 
agreement. 


è Copies of regular post implementation review reports. 


Fa NS 


Appendix _ xlvi 


CC-0. Bhagavad Ramanuja National Research Institute, Melukote Collection. 


Funding: IKS/Tattva Heritage. Digitization: Sarayu Trust/eGangotri 


Glossary 


Analysis 


Analysis means breaking a problem into successively manageable parts 
for individual study. 


Afferent module 
A module that obtains its input from its subordinates and delivers it 
upward to its superordinate(s). 


Aliases 
An alias, is an alternative name for a data element. 


Alpha testing 
Verifying and studying software errors and failures based on simulated 
users requirements. 


Artificial test data 
Are solely for test purposes. They are to be generated to test all 
combinations of formats and values. 


Automated systems 
These are nothing but man-made systems that interact with or are 
controlled by one or more computers. 


Batch Processing system 

In batch system, information is usually retrieved on a sequential basis, 
which means that the computer system reads through all records in its 
database, processing and updating those records for which there is 
some activity. 


Beta testing i 
Subjecting modified software to the actual user site (live) environment. 


Central functions 
These are usually left in the middle after the afferent and efferent 


functions are identified. Central functions are. the main work of the 
system. They transform the major inputs into major outputs. 


Cohesion ; ; 
Strength of relations within modules. A measure of the strength of 


functional association of processing activities (normally within a single 
module). 
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Constant data 
This implies to data that are the same for every entry. 


Coupling A 
It is the strength of relation between modules. A measure of the 
strength of interconnection between one module and another. The 
degree of dependence of one module on another, specifically, a measure 
of the chance that a defect in one module will appear as a defect in the 
other, or the chance that a change to one module will necessitate a 
change to the cther. 


Context diagram . 
This will be the most general diagram, really a bird’s eye view of data 


movement in the system. 


Control : 
In a system, the element or component that governs the pattern of 
activities of the system. 


Conversion r 
Conversion is the task of translating the user’s current files, forms, and 
databases to the format required by the new system. 


Data coupling 
A form of coupling in which one module communicates information to 
another in the form of elementary parameters. : 


Data Dictionary 

It is an organised listing of all the data elements that are pertinent to 
the system, with precise, rigorous definitions so that both user and 
system analyst will have a common understanding of all inputs, 
outputs, components of stores, and intermediate calculations. 


Data Elements 
Data elements the most fundamental data level. 


Data flow 
Movement of data in a system from a point of origin to a specific 


destination-- indicated by a line and arrow. 
Data Flow Diagram 


The modelling tool that we use to describe the tr 4 : 
into outputs is a data flow diagram posormation panne 
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Data stores 

Data stores could be thought of as the ‘memory’ of the system. In a data 
flow diagram, a storage area for collecting data input during processing; 
the symbol is a open rectangle. 


Database Design 
It involves designing the conceptual model of the database. 


Data structure 
One or more data elements in a particular relationship, usually used to 
describe some entity. 


Decision tables 

A decision table is created by listing all the relevant variables 
(conditions/inputs) and all relevant actions on the left side of the 
table.(The variables and actions have been separated by horizontal line). 


Decision tree 

A decision tree is a diagram that presents conditions and actions 
sequentially and thus shows which conditions to consider first, which 
second and so on. 


Design 
The (iterative) process of taking a logical model of a system, together 


with a strongly stated set of objectives for that system, and producing 
the specification of a physical system that will meet those objectives. 


Design Specification : 
This is the document produced at the end of systems design. 


Documentation ; 

A thorough written description of all the component parts and 
operations of the system. Includes forms, personnel, equipment, and 
input/output sequence. Both written and charted explanation 1s usea. 


Domain A ; ; 
The set of values of a data clement that is a part ofa relation. Effectively. 


equivalent to a field or data element. 


Efferent module 3 ; ; : 
A module that obtains its input from its superordinate(s) and delivers it 


downward to its subordinate(s). 
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End-users 
End-user is widely used by system analysts to refer to people who are 


not professional information system specialists but who use computers 
to perform their jobs. 


Exploding 
Going from higher level to lower is called ‘exploding’ a data flow 


diagram. 
External Entity 


They are organisations, other information systems, departments or 
people which represent a source or destination of transactions or data. 


Factored 
A function or logical module is factored when it is decomposed into sub- 
functions or submodules. 


Factoring 


The separation of a function contained as code in one module into a 
new module of its own. 


F cecibility study 

An important ouicome of the preliminary investigation is the 
determination that the system requested is feasible, which is done 
through feasibility study. 


First normal form 


A relation without repeating groups (a normalised relation) but not 
meeting the stiffer tests for second or third normal form. 


Fixed length record 
When the number and size of data item in a record are constant for 
every record, it is called fixed record length. 


Flexibility 

A measure of the degree to which a system i . 
variety of ways. system, as is, can be used in a 
Functionally dependent 


Data item is functionally dependent if its value i : 2 
with a specific data item. e 1s uniquely associated 
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Implementation 


Includes all those activities that take place'to convert from old system to 
the new. Ss 


Information System 

Can be defined as a subsystem of the business. Specifically, it is an 
arrangement of interdependent human and machine components that 
interact to support the operational, managerial, and decision-making 
information needs of an organisation. 


Live test data ‘ 
Are those that are actually extracted from organisation files. 


Logical data flow diagram 
It is the model of the proposed system. 


Manuals f t obi 
A form of documentation to guide employees in doing their tasks. 


Model $ ; 
A pictorial representation of a system: 


Module 

A module is defined as a set of instructions which can be invoked by 
name. It is a group of instructions, i.e., a paragraph, block, subprogram, 
subroutine or the like. 


Nassi-Schneiderman charts (or N-S charts) 
These are graphic tools that force the designer to structure software that 
is both modular and top-down , 


Normalization : 
Normalization is a process of simplifying the relationship between data 
elements in a record. it is the transformation of complex data stores to a 
set of smaller, stable data structures. 


On-line system T 
A system which accepts input directly from the area where it is created 
and in which the output or results of computation are returned directly 


to where they are required 


Physical data flow diagram 
It is a model of the current system. 
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Process (transform) € 
Processes transform inputs into outputs. They are work or actions that 


are performed by people, machines, or computers on incoming data 
flows to produce outgoing data flows. 


Prototype ; 
It is a working system - not just an idea on paper - that is developed to 


test ideas and assumptions about the new system. 


Record 
A group of related fields of information treated as a unit by an 


application. Also called a data structure. 


Record Key 

To distinguish one specific record from another, one data item is 
selected in the record that is likely to be unique in all records of a file 
and use it for identification purpose. 


Relation 

A ‘relation’ is a two-dimensional table. It consists of ‘rows’ which 
represent records and columns which show the attributes of the entity. 
A relation is also called a file, it consists of a number of records. 


Reliability 
A measure of the quality of a program or system; sometimes expressed 
as mean-time-between-failures. 


Rule ; 
In forms design-- a rule (line) guides the human eye in reading and 
writing data groups and separates them on the form. 


Second Normal Form , 
A normalised relation in which all of the nonkey domai 
functionally dependent on the primary key. ey domains are fully 


Shared (library) modules 
These are predefined procedures that are included in th if 

> oced ; e system’s 
program library. The routine is quickly invoked by a single command or 


Software Engineering 
Is the application of science and mathematics by which the capabilities 


of computer equipment are made useful to man vi 
procedures and associated. via computer. programs, 
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Source document 
This is the form on which data are initially captured, i.e. recorded. 


Span of control 


Span of control refers to the number of sub-ordinate modules controlled 
by a calling module 


Structured analysis 

Structured analysis is a development method for the ‘Anialyels of 
existing, manual or automated systems, leading to the development of 
specifications (i.e. Design) for a new or modified system : 


Structure chart : 

A graphic tool depicting the partitioning of a system into modules, the 
hierarchy and organisation of those modules, and the’ communication 
interfaces between the modules. 


Structured design 
A set of guidelines for producing a hierarchy of logical modules which 
represents a highly changeable YEE gs 


Structured English 
A tool for representing policies and procedures in a precise form of 
English using the logical structures of sraceuraa coding. ` 


Structured flowcharts 

Also called Nassi-Schneiderman charts (or N-S charts), are graphic’ tools 
that force the designer to structure software: that is both modular’ and 
top-down 


Structured programming 
A set of guidelines and pected for writing | orane as a nested set 
of single entry, single-exit blocks of code, using a restricted number of 


constructa 


Stractured walkthrough i ui eas 
Interchange of ideas between peers ith reviews a product presented by 
its author and agree on the validity of a proposed solution to a problem. 


Subsystem ©» $ l pile: 
A series or group of components that perform one or more operations of 
a more complex system. 
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System : 
It is an orderly grouping of interdependent components linked together 
according to a plan to achieve a specific objective. 


Is the process of totally understanding the current system by gathering 


and interpreting facts, diagnosing problems, and using the facts to 
improve the current system. 


System Design al : 
Detailed concentration on the technical and other specifications that 


will make the new system operational. 


Systems development life cycle 
This is a sequence of events carried out by analysts, designers and 
users to develop and implement an information system. These activities 
are carried out in different stages. 


System Maintenance i : 
Is performed most often to improve the existing software rather than to 
respond to a crisis or system failure. 


System Testing 
Testing the whole system by the user after major pro s and 
subsystems have been tested. tee 


Tabular format 
This implies to a row-and-column format. 


Testing 
The critical phase of computer system development in which debugged 
programs are tested to ensure a working system. 


t 


Third Normal Form ; 
A normalised -elation in which all of the nonkey domains are fully 


dependent on the primary key and all the n nk i ‘ 
ae onkey domains are mutually 


Transaction 


Any element of data, event, or change of state that init 
Some action or sequence of actions, usually an input. AEA orenuhates 
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Transaction analysis 


It is the technique of identifying transaction types of a system using 
them as units of design. 


Transform analysis 


It is the strategy for converting each piece of the data flow diagram into 
a structure chart. Transform analysis is a ‘strategy’ not an algorithm. 


Transitive dependency 
Occurs when some of the non-key attributes are dependent not only on 
the primary key but also on a non-key attribute. 


Tuple 

A specific set of values for the domains making up a relation, it is the 
«relational term for record. An individual data structure or record ina 
relational database. ` 


Unit Testing 
This involves the tests carried out on modules/programs which make 
up a system. 


Validation - 
Checking the quality of software in both simulated and live 
environment. 


Variable data 
Those data items that change for each transaction handled or decision 


made. 
Verification testing 


Runs the system in a simulated environment using simulated data. This 
simulated test is sometimes called alpha testing. 
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